Re: http progress notification

On 26/05/2010 11:36 a.m., Henrik Nordström wrote:
> ons 2010-05-26 klockan 11:09 +1200 skrev Adrien de Croy:
>    
>> However excluding Progress from responses to HTTP/1.0 messages does seem
>> prudent.
>>      
> Personally I am not sure it needs to be mentioned for the reasons given
> before. The amount of proxies in use today and not supporting Connection
> SHOULD be minimal.
>
>    

OK fine by me.

>
>> I wondered about that.  It's not a common header, and I don't know of
>> any browsers that use it to make a handling decision instead of
>> Content-Type.
>>      
> Every browser I tried..
>
>    

OK, I'll have another look.  I think I didn't consider the case where 
both are present.  So Content-Disposition typically overrides handling 
which otherwise is dependent on Content-Type?

In that case we definitely need to transport that header through as 
well.  This leads us to requirements (since there are potentially many 
1xx response messages) about which 1xx message(s) should contain these 
headers.  I'd propose that only one of them should.  It may not always 
be possible for this to be the first interim response (e.g. if there is 
a 1xx sent back when the proxy is connecting upstream), but it's 
possible from the stage where the agent doing the processing receives a 
final result from upstream.

>> OK, that could be quite good, then a downstream proxy can make policy
>> decision based on content type etc as early as possible.
>>
>> So it's not in violation to send entity headers when there can be no
>> entity (in a 1xx response message)?
>>      
> I do not think so. Especially not with this being a hop-by-hop
> negotiated feature.
>
>    

OK, in which case I'm tending to side with Julian in that we should use 
another status than 102, since there is more non-standard (in terms of 
the existing 102 requirements) processing potentially required by clients.

>> I thought about that too, but the target for the text in the agent value
>> (only currently proposed text field) is a human, and so I thought it
>> would be preferable not to include things like version numbers etc etc.
>>      
> I disagree, for the exact same reason those are in Server. The agent
> name is mostly for diagnostic purposes, not to be human friendly.
>
>    

Our Chromium implementation actually builds the status string displayed 
to the user using the agent value.  Perhaps "agent" isn't the best name 
for this parameter (subject is the linguistic equivalent).  It's not 
like the User-Agent header.

So the user sees status messages in the status bar like

WinGate is downloading (1.2MB of 2.7MB)
WinGate is downloading (1.4MB of 2.7MB)
WinGate is downloading (1.6MB of 2.7MB)
etc
Kaspersky AV for WinGate is processing (10%)

Most people surfing through a corporate firewall at some stage become 
aware of its existence and its product name.  For instance error pages 
(cannot connect to server etc) commonly have branding on them from the 
firewall/proxy vendor.  Block pages from AV have their branding.

So there is value in using recognisable names in status updates.

the added benefit of using the "product" name here, is that product 
names are less likely to require localisation.

If we need more information for forensic purposes, the thing generating 
the 1xx response could add a complete Server header.

Regards

Adrien


>> So the intention was just a simple label.  More like a realm for auth.
>> Something the human will hopefully recognise (or learn to).
>>      
> which is not an agent description, but more like a state description.
>
> Regards
> Henrik
>
>

Received on Wednesday, 26 May 2010 00:12:54 UTC