cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glynn, Eoghan" <>
Subject RE: Identification of Partial Responses
Date Mon, 15 Jan 2007 16:58:02 GMT

> -----Original Message-----
> From: Dan Diephouse [] 
> Sent: 12 January 2007 16:19
> To:
> Subject: Re: Identification of Partial Responses
> So I would argue that we use a content-type for all 
> request/responses (and not just partial responses) and 
> possibly check the response codes if we're worried about 
> messages without content types.

I'm fine with using the content-type as the primary determining factor. 

But I think there's no harm in being as tolerant as possible to
potential mis-behaviour by the server-side HTTP engine.

The algorithm I suggested in my last mail would allow for multiple
different ways of detecting an empty entity body:

1. content-type == null
2. content-length == 0
3. transfer-encoding == chunked, first chunk empty
4. connection:close set, EOF on entity-body read

> > Trust me, we've returned to the drawing board many times on 
> this one 
> > :) And we keep coming to the same conclusion, that partial 
> responses 
> > in some form are required, and these must be 
> distinguishable from full 
> > responses.
> So, with the exception of this email thread, I haven't been 
> questioning the need for them, but rather attempting to find 
> a more non-invasive way to implement them. I don't think it 
> was fruitless however. We've learned who exactly implements 
> this functionality, some interop requirements (http 200), 
> documented why we need the functionality (I'll write this up 
> soon too), and determined a better way to check for response 
> messages in HTTP. Whats more I feel like I can actually 
> contribute to this part of the code base now, answer 
> questions about it on the mailing list, and brag about our 
> ability to handle partial responses :-)
> Sorry if I've been a complete PITA about this, but I need to 
> be able to justify things to other people as they judge CXF 
> (and myself) on them. I have already gotten questions and 
> strange looks (and I'm not speaking figuratively here) on 
> parts of the API in the Transport layer. People ask why they 
> should have to worry about partial responses, what they are, etc.
> While I understand them whole lot better now, the semantics 
> are still difficult to explain to someone not fully versed in 
> RM an WS-A - aka your average developer doing webservices.

Totally agree that questioning the group-think is good.

However for pure time-mgmt reasons, I wanted to hasten the discussion to
a firm conclusion.
> Hence my proposal on the mailing list on removing the 
> decoupling support from the transport layer. That proposal 
> doesn't remove the partial response functionality, but simply 
> moves things around. Are you still against that?
> I'm not saying that you have to go out and make the changes, 
> I am more than willing to do what is necessary.

It not who does the work that concerns me ... I'm afraid I still
disagree with your proposal to move the decoupling logic out of the
transport. Now, I just realized that I didn't reply to your last mail on
the "Proposal for Decoupling and Issues with CXFServlet" thread, so I'll
do that right away, and hopefully clarify my thinking a bit.


View raw message