- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Thu, 27 May 2010 15:45:20 -0700
- To: Adrien de Croy <adrien@qbik.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
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. 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 22:45:49 UTC