W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2010

Re: Concurrent non-error response disallowed. ("clarification of 7.2.2. Monitoring Connections for Error Status Messages")

From: Jamie Lokier <jamie@shareable.org>
Date: Wed, 19 May 2010 03:53:03 +0100
To: Henrik Nordström <henrik@henriknordstrom.net>
Cc: Wenbo Zhu <wenboz@google.com>, ietf-http-wg@w3.org
Message-ID: <20100519025303.GI2318@shareable.org>
Henrik Nordström wrote:
> fre 2010-05-14 klockan 15:16 -0700 skrev Wenbo Zhu:
> > Then the question remains: 1) the behavior is disallowed by the spec
> > as it's not reliable - due to proxies (if not ideologically); or 2)
> > the behavior is supported, with all the implementation caveats and
> > related best-effort/fall-back concerns.
> Imho 2.
> It is certainly the case that servers are allowed to respond early
> before they have received the whole request. The only caveat there is
> that the server must not block on writing if the client doesn't read the
> response yet and need to continue reading the request while it's sending
> the response.

I agree.

> But it's very unusual behavior to complete the response down to the
> final octet and signal end of response and still require the rest of the
> request to be sent, and I would advice to stay away from any such
> designs. Better make sure that there is some part of the response left
> to send after receiving all of the request. Could be as little as the
> end chunk when using chunked encoding or connection close if using
> neither content-length or chunked. As long as you don't signal
> end-of-response until all of the request have been received.

I agree with the above - it's good advice.

-- Jamie
Received on Wednesday, 19 May 2010 02:53:57 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:53 UTC