- From: Henrik Nordström <henrik@henriknordstrom.net>
- Date: Fri, 28 May 2010 00:25:18 +0200
- To: Adrien de Croy <adrien@qbik.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
fre 2010-05-28 klockan 09:56 +1200 skrev Adrien de Croy: > 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. A header saying that you do not want notifications perhaps? But I don't see it likely to be used much, and in those few situations where I can see it being usedul it can just as well be handled by the closest proxy with a local policy. > 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). It also means that every client which supports this need to add more overhead to all their requests, plus that existing clients will not benefit at all from servers supporting progress notifications and will still suffer from timeouts. By not requiring negotiation all existing clients will immediately benefit from the new messages keeping the connection alive, and avoid clients or network equipment timing out the transaction. The likelyhood that the progress notifications break existing software is fairly small, and then only when using software not compliant with RFC2616 (MUST level requirement to not crash & burn due to unexpected 1xx responses). Regards Henrik
Received on Thursday, 27 May 2010 22:25:59 UTC