- From: Adrien de Croy <adrien@qbik.com>
- Date: Mon, 17 May 2010 10:53:49 +1200
- 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 UTC