On 1/15/07, Glynn, Eoghan <[EMAIL PROTECTED]> wrote:
> -----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
This doesn't work for all cases though. If I grab a zero length file via a RESTful interface by your logic there is no message - but there is. If we want additional checks beyond checking the content-type header, we should look at the http response code. This is the optimal logic as relayed to me by Greg Wilkins (author of Jetty) and I don't really see what the above logic buys us. Is there some specific use case you had in mind the content type/response code logic doesn't handle? - Dan -- Dan Diephouse Envoi Solutions http://envoisolutions.com | http://netzooid.com/blog
