- From: Henrik Nordström <henrik@henriknordstrom.net>
- Date: Fri, 14 May 2010 13:02:32 +0200
- To: Joe Orton <joe@manyfish.co.uk>
- Cc: ietf-http-wg@w3.org
fre 2010-05-14 klockan 11:11 +0100 skrev Joe Orton: > I can't find that explicit requirement in 2616; am I missing it, or > should it simply be implied from the MUST requirement to forward Expect? It's implied form - Only mention of 100 in relation to proxies is MUST forward, except when it MUST NOT or MAY NOT forward. - The only entity mentioned in creating 100 responses is explicitly origin servers which either MUST, MUST NOT or MAY generate 100 responses depending on the conditions, not servers in general. Plus the general function of Expect + 417, See below. The main reason why proxies should not normally generate 100 responses is the same reason why 100 responses were added, the need of providing a clean forwarding path where the client knows the server is willing to accept the request without obvious waste of network resources should the server (or proxy) want to reject the request. A proxy responding with 100 Continue breaks this as it does not yet know the request body can or should be forwarded. And if you apply this recursively in a chain of proxies then the breakage becomes more apparent. The proxy MAY however add Expect: 100-continue provided it's then prepared to deal with 417 responses without bothering the client, but doing so is not trivial as it requires storing a copy of the request until a response of some kind is seen, allowing the proxy to reforward the request without Expect: 100-continue should a 417 response be seen. For similar reasons proxies MUST NOT respond with synthesized 100 Continue responses to Expect: 100 Continue, as this breaks any handling of 417 responses to the Expect. It's not valid to send or forward 417 after sending 100 Continue. So if a proxy synthesizes 100 Continue in response to Expect: 100-continue it must also save a copy of the request data until a response is seen and then reforward without Expect: 100-continue if a 417 is seen, BUT this is incompatible with the requirement that proxies MUST forward Expect headers which leaves the proxy in the unfortunate situation that it should not forward the 417 and MUST NOT reforward the request without Expect.. All in all, attempting to deal with adding 100 Continue or adding/removing Expect: 100-continue in a proxy is a complex matter with quite subtle cases you have to deal with to not break the protocol expectations of the requesting client. The only case where it's reasonably safe is after a considerable delay in response to 2068 requests without Expect: 100-continue. And then only to work around old clients who don't implement Expect: 100-continue and which also do not implement a timer themselves when seeing that the proxy is HTTP/1.1. Proxies MAY however drop 100 responses if either the request was without Expect: 100-continue or of the client have already started to send the request body. This is a harmless optimization of the protocol. Regards Henrik
Received on Friday, 14 May 2010 11:03:43 UTC