- From: Henrik Nordstrom <henrik@henriknordstrom.net>
- Date: Sun, 06 Apr 2008 01:16:52 +0200
- To: Charles Fry <fry@google.com>
- Cc: Julian Reschke <julian.reschke@gmx.de>, Brian McBarron <bpm@google.com>, google-gears-eng@googlegroups.com, Mark Nottingham <mnot@yahoo-inc.com>, HTTP Working Group <ietf-http-wg@w3.org>
fre 2008-04-04 klockan 20:08 -0400 skrev Charles Fry: > Hmm. Now this is starting to come full-circle. As I understand it the > whole reason that Expect: 100-continue is used in conjunction with 100 > Continue responses is to ensure, as the request is finding its way to > the origin server, that the response will be able to find its way > back, being properly interpreted as an intermediate response. Without > this there is the risk that a non-100-continue-aware proxy would > interpret the 100 response as a final response. Not really. It's more about avoiding the heuristics on how long a client should wait for 100 Continue. But unfortutately it failed due to HTTP/1.0 and RFC2068 being part of the picture... > Is this not a requirement of any client-elicited 1xx response? I.e. > can we really just send 103s when they aren't asked for, with full > confidence that they won't break anything as they travel back to the > client? Yes, if the request was received as an HTTP/1.1 request. At least from a specifications point of view. (not entirely sure about actual implementations..) Regards Henrik
Received on Saturday, 5 April 2008 23:18:54 UTC