- 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
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