[jira] Commented: (AXIS2C-936) On incomplete response message, the client receives response data for the elements up to the error, but no indication of the error

["Bill Mitchell (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/AXIS2C-936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12563044#action_12563044 ] 

Bill Mitchell commented on AXIS2C-936:
--------------------------------------

Looking at this again in the log, it would be more clear if the error message read something like:
"element getExemplarResponse is not complete".  

> 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