Re: update: http progress notification

On 28/05/2010 10:45 a.m., Roy T. Fielding wrote:
> On May 27, 2010, at 2:56 PM, Adrien de Croy wrote:
>    
>> OK, so HTTP/1.0 is covered in any case, since 1xx responses are not allowed to HTTP/1.0 clients.
>>
>> That just leaves the issue of whether a client should indicate support (or desire) for progress notifications or not.
>>
>> I'm a little bit reluctant to suggest the progress notifications should not require any indication from the client.  If only because some clients may want to be able to suppress generation of such messages for whatever reason.
>>
>> So I think my preferred option is a Progress token in the Connection header.  That way I don't have to try and dream up something useful in terms of parameters for a potential Progress request header.  It also means clients that aren't written (e.g. existing clients) to process these messages won't receive them for discarding and waste bandwidth (esp over slower high-cost circuits such as GPRS / G3 etc).
>>      
> Sending an additional 10 to 30 bytes on every single request,
> in the critical path, just in case the browser might access
> such a resource (a one in a billion chance, at best), is an
> extremely poor trade-off.
>
>    

actually if you're behind a corporate firewall that does this, it's 
closer to a 100% chance depending on scanning rules for the firewall 
AV.  When we deploy this with WinGate and AV, that will then be millions 
of browsers (and other HTTP agents) seeing these 103s for pretty much 
all requests if we don't negotiate.  I've tested Chrome, FF and IE8, but 
I haven't tested things like windows update, BITS service etc etc etc.  
There's no way to guarantee what won't break.

I was of the impression switching behaviour based on User-Agent was 
frowned upon.  It creates at best a maintenance issue for admins 
(keeping the list of UAs current).

I agree it will be a long time before origin servers generate them.  So 
probably it makes no sense for now for a proxy to forward the Progress 
token upstream, unless it's talking to another proxy.  So actually I 
don't see many of these going over the wire onto the net. The main 
benefit is for a client talking to a local proxy.  RFC2616-compliant 
proxies that don't understand Progress will already strip it.

I don't know of any browser that doesn't already include a Connection 
header in every request already for keep-alives (even through default 
semantics for 1.1 is to keep alive so it's largely redundant), so 
overhead in practise will only be an extra 10 bytes.

Also, clients could make some choices about likelihood of benefit before 
adding Progress to the Connection header.  E.g. for retrieving images, 
JS, CSS etc it could be turned off.

Or behaviour could differ for proxy connections vs direct and be 
configurable in the browser.

Otherwise if we don't advertise support, and it's on by default, we need 
to resort to things like administrative settings, e.g. admin can turn it 
off/on per client IP or UA or Content-Type or something.  That loads up 
burden on the admin.

As for Henrik's point about benefit for non-supporting clients, where 
these messages will stop connection timeouts.  I can understand a client 
may consider something is happening, but if there is no progress 
indicated to the user, we are back at square one (where we are now), 
where the user hits retry a few times then calls his tech support or 
admin.  So I don't think the benefit will be there for browsers.  Other 
agents certainly may benefit.

Maybe the answer to that is a positive exception mechanism.  E.g. proxy 
sends progress to anyone that asks for it, plus a list of extras that 
didn't.

Adrien

> If you want this feature to be deployable, then don't rely on
> negotiation.  It isn't going to happen.  Use the user-agent.
>
> ....Roy
>
>
>

Received on Thursday, 27 May 2010 23:41:22 UTC