> -----Original Message----- > From: Dan Diephouse [mailto:[EMAIL PROTECTED] > Sent: 12 January 2007 16:19 > To: [email protected] > 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. Cheers, Eoghan
