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

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.

It is also the case that the spec do not require clients to abort the
request if seeing an early non-error response.

Imho the case of a server that streams the response as the request is
coming in is a perfectly legal application of HTTP. An example of such
service whould be a translation service which translates on the fly
without buffering the whole request.

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.

Regards
Henrik

Received on Saturday, 15 May 2010 07:49:15 UTC