W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2008

Re: [google-gears-eng] Re: Deploying new expectation-extensions

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>
Message-Id: <1207606910.3973.18.camel@HenrikLaptop>

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

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.

4xx response
modified request to meet server requrements
100 Continue
request data
2xx response

how is that not a negotiatated transfer?

Received on Monday, 7 April 2008 22:24:22 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:45 UTC