[
https://issues.apache.org/jira/browse/AXIS2C-936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Blough updated AXIS2C-936:
-------------------------------
Labels: patch (was: )
> 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
> Assignee: Damitha Kumarage
> Priority: Major
> Labels: patch
> Attachments: TemplateSource.diff
>
>
> 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 was sent by Atlassian JIRA
(v7.6.14#76016)
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscr...@axis.apache.org
For additional commands, e-mail: c-dev-h...@axis.apache.org
