cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dan Diephouse" <>
Subject Re: Identification of Partial Responses
Date Thu, 11 Jan 2007 17:30:03 GMT
On 1/11/07, Glynn, Eoghan <> wrote:
> > 1. Remove isPartialResposne from HTTPConduit - this logic
> > isn't right as it depends on a certain HTTP response code. I
> > think the best way to test to see if we have a response
> > message is to just check and see if the contentType is null.
> > If it isn't, there is a message. If it is null, then there is
> > no message.
> Well, null content-type or zero content-length, not sure which is most
> general and reliable indicator.
> Currently the logic is reponseCode == 202 && contentLenght != 0, so we
> could simplify this to contentLenght != 0, or check for null-ness of the
> content-type instead as you suggest.

Content-Length will often times not be set though as many people need to do
a chunked responses.

> 2. RM logic shouldn't need anything special now, just
> > recognition of a <SequenceAcknowledgement> in response to a
> > one way message.
> Remember the SequenceAcknowledgement could also be in a partial response
> to a twoway request (case B as described in an earlier mail on this
> thread).
> 3. Remove isPartialResposne from ClientImpl. This call is
> > really superflous as we are going to return as soon as the
> > one way message is sent anyway - we aren't blocking for a
> > response since we check for isOneWay on line 160.  We should
> > also change our logic so that we only look for response
> > objects if the call is one way.
> Are you assuming that partial responses are only sent for oneways?
> If that were the case, then the full/partial response recognition issue
> would indeed go away.
> But alas, case B requires that twoway requests may also attract partial
> responses. In this case, we would indeed be waiting for a full response
> in ClientImpl, so we need to be able to make the distinction between
> full and partial responses in ClientImpl, so I can't see how the
> ClientImpl.isPartialResponse() logic is superfluous.
> Recall the issue that got this whole discussion started ...
> distinguishing a partial and full response to a bare doc/lit *twoway*
> operation with void return type. The <SOAP:Body/> is empty in both
> responses, hence the need to distinguish in some other way.

Ah shit, forgot about the two way case.

*heads back to drawing board*

Dan Diephouse
Envoi Solutions |

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message