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

Re: Expect: 100-continue and proxies

From: Adrien de Croy <adrien@qbik.com>
Date: Mon, 17 May 2010 10:53:49 +1200
Message-ID: <4BF0777D.5050102@qbik.com>
To: Henrik Nordström <henrik@henriknordstrom.net>
CC: Joe Orton <joe@manyfish.co.uk>, ietf-http-wg@w3.org
Hi

with reference to 
http://tools.ietf.org/id/draft-decroy-http-progress-04.txt which was the 
last iteration of the proposal, the issues I see needing some further 
discussion are:

1. what form a client advertisement of support for Progress should 
take.  The I-D currently proposes a request header called Progress.  
Another option could be a Connection token.  E.g. Connection: 
Keep-alive, Progress.  This would (should) then be stripped from 
requests by proxies, which could be safer, in that the proxy handling 
Progress would therefore also be sure to handle multiple 1xx responses 
from upstream. A compliant proxy could re-add such a header, although it 
makes no sense to add the header if the client did not initially provide it.

2. Whether or not it makes any sense for a client to suggest relevant 
timeframes for progress.

3. Whether it makes any sense to really limit rate of interim 
responses.  For instance for a local proxy well-connected to the client, 
why limit updates to max 1/s

4. How best to transfer messages for humans.  One suggestion was to use 
a set of well-known tokens that would be universally understood, and 
could therefore be appropriately localised by the browser.

There are also potential issues with what to do about streamed 
(unending) media content.  This is currently not contemplated by the 
I-D, and potentiall falls outside its scope, although it's another issue 
related to gateway scanning.  My feeling is that progress notifications 
provide benefit in a number of situations so perhaps it's best to keep 
it simple so it can proceed, I don't think it will resolve issues around 
pending / spooling of media content, and in fact I think the only way 
around that would be some other mechanism to explicitly address that 
issue (e.g. Origin servers mark content as non-ending somehow).

In terms of progressing, it would be useful if some browser vendor(s) 
were interested, to get some prototype implementation going for testing 
and evaluating the best way forward.  I can provide a proxy for testing 
fairly quickly.


Cheers

Adrien



On 14/05/2010 11:57 p.m., Henrik Nordström wrote:
> fre 2010-05-14 klockan 23:20 +1200 skrev Adrien de Croy:
>
>    
>> does this really apply to all 1xx responses, or just 100-continue (which
>> is the only one defined for Expects)?
>>      
> I would assume that new 1xx codes can be specified to be generated by
> any server, proxies included. I do not see any reason why not.
>
>    
>> On that note, is  there any interest in resuscitating this I-D?  It's
>> still a major problem (AV scanning at an HTTP gateway).  In fact the
>> problem just keeps getting worse.
>>      
> I think it's a good idea, and this is a good place as any to discuss it
> even if outside httpbis charter.
>
> What remains to be done in the spec as such?
>
> Regards
> Henrik
>
>
>
>
>    
Received on Sunday, 16 May 2010 22:55:07 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:18 GMT