- From: Henrik Nordstrom <henrik@henriknordstrom.net>
- Date: Tue, 13 Feb 2007 22:44:02 +0100
- To: Adrien de Croy <adrien@qbik.com>
- Cc: ietf-http-wg@w3.org
Received on Tuesday, 13 February 2007 21:44:15 UTC
tis 2007-02-13 klockan 12:49 +1300 skrev Adrien de Croy: > That wasn't my intention. 100 continue in practice can be hop by hop, > as a proxy can send it back to a client (or is this prohibited?). My understanding: RFC2616 does not intend for proxies to send 100 Continue on their own, only forwarding of server generated 100 Continue. Proxies generating 100 Continue on their own messes up the HTTP version cache of the client and may falsely fool the client into thinking that the server has accepted the request and is ready to receive the response. 100 Continue and it's related delay in sending the request body has two purposes a) Avoiding wasting bandwidth on large request bodies which will be ignored by the server anyway, allowing the client to abort the request early withoutsending the body (by closing the connection or terminating chunked encoding). b) To a client receiving 100 Continue this is supposed to mean the request as such has been accepted by the origin server and it's now ready to process the body. Regards Henrik
Received on Tuesday, 13 February 2007 21:44:15 UTC