cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dan Diephouse" <...@envoisolutions.com>
Subject Re: Identification of Partial Responses
Date Mon, 15 Jan 2007 21:40:48 GMT
On 1/15/07, Glynn, Eoghan <eoghan.glynn@iona.com> wrote:
>
>
>
> > -----Original Message-----
> > From: Dan Diephouse [mailto:dan@envoisolutions.com]
> > Sent: 12 January 2007 16:19
> > To: cxf-dev@incubator.apache.org
> > 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

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