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

Henrik Nordstrom wrote:
> 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.
>
>   
what does the client then do in that case?

Seems to me that getting around message - length / connection 
maintaining issues by using chunking so you can send a premature final 
chunk instead of terminating the connection is asking for a whole lot of 
pain.  It's an ugly hack.

For starters, there's then no way to tell the recipient that the 
completion was an abortive one.  If there are several processes in an 
intermediary or end server that the data goes through before getting to 
the module that caused the client to abort, then you've got all manner 
of things may happen to that data which appears complete.

That's where it would have been useful to support notifying an abortive 
end ( e.g. previously discussed negative 1 chunk length ) to a 
transfer.  Abort without closing.

All in all I think using chunked uploads is bad for many reasons, apart 
from the fact that it's probably poorly supported even in existing 
HTTP/1.1 infrastructure.  Using it so you can stop sending a body is 
even worse.

>> 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.
>   
Is it just me that finds the idea of a user agent maintaining a list of 
servers and their versions and capabilities a bit desperate?  There are 
a lot of servers out there.  If we start relying on this sort of 
behaviour, what complexity ( = bugs) does this behaviour add, and what 
about all the boundary conditions it creates.

Just seems like a bad idea to rely on that sort of heuristic.

> 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.
>
>   
OK, but I've never seen one.

>> 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?
>   
that's just one scenario of many upload scenarios.  Take out the 100 
Continue and you don't have pre-agreement (negotiation).  And its so 
incredibly inefficient.  In that original request, many browsers even 
now send the entire entity body. Other browsers who think they might be 
challenged for auth send the initial POST with Content-Length 0, 
regardless of whether they actually will be challenged or not.  A proxy 
that tries to save the client sending the whole body can do nothing 
except terminate the connection, and then there's no guarantee the 
client won't just repeat the same request.

As I said, it's possible ("a client can") to have a connection followed 
by initiation of a large transfer without any notification of acceptance 
by the thing that will have to swallow the data or reject and disconnect.

If you want proof of the problem, try uploading a 100MB file across a 
slow WAN through a proxy that requires auth to a poorly-connected server 
that requires auth (a fairly common scenario actually).  Basically 
impossible because depending on the auth method, that 100MB may have to 
be sent up to 6 times.  Any connection-based auth cannot get around this 
in any reasonable way (yes I know how many people hate NTLM for being 
allegedly non-compliant, but tens if not hundreds of millions of people 
have to live with it).

Proper negotiation would solve this, but would need to take the form of 
establishing in advance permission to upload a body without requiring 
that body to be present in the message that establishes the permission.  
E..g a probe command, or the equivalent of HEAD for POST.

Try an analogy - e.g. a fertiliser delivery company.

the HTTP way:

* The truck turns up and starts dumping fertiliser in your driveway
* you come out and scream at it.
* it stops
* you clean up
* maybe it comes back and dumps some more fertiliser in your driveway 
soon after

Pros:
* delivery co didn't need to spend time calling in advance if you really 
did want the fertiliser
Cons:
* had to send that truck all that way. If you didn't want it, that's a 
big waste
* Even if you didn't want it, you and the delivery company both have to 
sink resources into it.

The proper/polite way (real apriori negotiation)

* the delivery company rings you and checks if it's ok to send the truck 
around
* you say no thanks or yes please.

Pros:
* don't waste money sending a truck around if the recipient didn't want it
* don't waste recipient's time and energy cleaning up
Cons:
* the cost and time relating to a phone call

Add in authentication steps and it gets even more ridiculous. 

Cheers

Adrien


> Regards
> Henrik
>
>   

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com

Received on Tuesday, 8 April 2008 01:44:10 UTC