- From: Henrik Nordstrom <henrik@henriknordstrom.net>
- Date: Tue, 08 Apr 2008 00:21:50 +0200
- To: Adrien de Croy <adrien@qbik.com>
- Cc: Jamie Lokier <jamie@shareable.org>, Charles Fry <fry@google.com>, 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>
tis 2008-04-08 klockan 09:40 +1200 skrev Adrien de Croy: > I'm going to have to disagree on that one, I don't think 100 Continue > does a particularly good job at all, for the following reasons. > > 1. It uses an ill-defined heuristic for what a client should do in the > absense of 100 continue. Which is due to HTTP/1.0 not supporting 100 Continue. > The suggested smart way around this is for > clients to "remember" which servers are HTTP/1.1, or to use chunked > uploads. chunked uploads and persistent connections is how it should have been from start. and as above the reason why it fails is HTTP/1.0 not supporting chunked. > That's just really bad design: doesn't cope with change, > imposes unreasonable requirements on clients, and denies the ability for > proxies to set efficient policy on upload size. Proxies needing up-front knowledge of the size can reject the request with 417. > 3. The common heurstics don't work through proxies well at all, due to > timing based on connection to local proxy. Chain more proxies and it > just gets worse. Not by much. But the heuristics do get quite ifuzzy if using a proxy and the request is to a host not recently contacted. But the more of the infrastructure becoming HTTP/1.1 the more aggressive clients can be about requiring 100 Continue. A client which has seen a HTTP/1.1 response from it's next hop can in fact in nearly all network configurations switch to be very aggresive about 100 continue on requests via that hop. > and finally, by no stretch of anyone's imagination is it a negotiated > transfer. A client can connect, and spew enormous amounts of resource > at a server without ever having received a byte in assent from it. > That's simply not negotiation in anyone's book. request 4xx response modified request to meet server requrements 100 Continue request data 2xx response how is that not a negotiatated transfer? Regards Henrik
Received on Monday, 7 April 2008 22:24:22 UTC