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

So at least we agree that there are valid use cases for supporting
concurrent responses; and the spec at least hasn't explicitly
disallowed such a behavior.

I briefly searched the mailing-list archive, and wasn't sure if this
subject has been brought up before. Regardless of which interpretation
httpbis chooses to support, there certainly have been enough
confusions among implementors that warrant further clarification in
the spec.

While there still may be incompatibility concerns, I'd be happy to see
that the spec permits concurrent (early) response, to avoid
introducing any non-compatible behaviors in implementing HTTP based
protocols.

- Wenbo



On Sat, May 15, 2010 at 12:48 AM, Henrik Nordström
<henrik@henriknordstrom.net> 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.
>
> 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 10:14:38 UTC