axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Mitchell (JIRA)" <j...@apache.org>
Subject [jira] Created: (AXIS2C-936) On incomplete response message, the client receives response data for the elements up to the error, but no indication of the error
Date Mon, 28 Jan 2008 02:49:35 GMT
On incomplete response message, the client receives response data for the elements up to the
error, but no indication of the error
----------------------------------------------------------------------------------------------------------------------------------

                 Key: AXIS2C-936
                 URL: https://issues.apache.org/jira/browse/AXIS2C-936
             Project: Axis2-C
          Issue Type: Bug
          Components: code generation
    Affects Versions: Current (Nightly)
         Environment: Windows XP, Visual Studio 2005, libxml or guththila, libcurl
            Reporter: Bill Mitchell


If the SOAP response message to the client is incomplete, i.e., there is an EOF indication
in the middle of the message, the client receives an object containing the elements that could
be deserialized from the message, with no indication that the message is incomplete.  Clearly,
the impact is that the client may act on the partial message, with no indication anywhere
that data was lost.  

I considered whether this could be fixed in svc_client.c.  Although it appears with the debugger
that the message is usually complete when at the end of axis2_svc_client_send_receive_with_op_qname(),
this appears to be an accident of the fact that the lower level code looks for a soap fault
in the soap body, and a SOAP 1.1 response does not have a fault in the body so the entire
body is scanned first looking for the fault.  I believe the intent is that the response be
returned without scanning all of the tokens in the body.   So it must be the responsibility
of the generated stubs to check that all the data is processed when deserializing the elements.
 

At the end of the deserialize method for the response message, there is code like the following:
     if(AXIS2_FAILURE ==  status)
     {
         AXIS2_LOG_ERROR(env->log, AXIS2_LOG_SI, "failed in setting the value for getExemplarResponse
");
         if(element_qname)
         {
             axutil_qname_free(element_qname, env);
         }
         return AXIS2_FAILURE;
     }
  }

  else if(!dont_care_minoccurs)
  {
      if(element_qname)
      {
          axutil_qname_free(element_qname, env);
      }
      /* this is not a nillable element*/
      AXIS2_LOG_ERROR(env->log, AXIS2_LOG_SI, "non nillable or minOuccrs != 0 element getExemplarResponse
missing");
      return AXIS2_FAILURE;
  }

My suggestion is that an additional test for node complete be added similar to this:
     if(AXIS2_FAILURE ==  status)
     {
         AXIS2_LOG_ERROR(env->log, AXIS2_LOG_SI, "failed in setting the value for getExemplarResponse
");
         ...
     }
     if(axiom_node_is_complete(current_node, env) == AXIS2_FALSE)
     {
         AXIS2_LOG_ERROR(env->log, AXIS2_LOG_SI, "failed to scan entire element getExemplarResponse
");
         if(element_qname)
         {
             axutil_qname_free(element_qname, env);
         }
         return AXIS2_FAILURE;
     }
  }

  else if(!dont_care_minoccurs)
  ...

It would probably be reasonable and safe to do this as part of all the generated deserialize
routines.  But in testing it appears sufficient to do this in the outermost response element
routine, as this assures an error is returned to the client if the response message is incomplete.



-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org


Mime
View raw message