Message-Id: <18.104.22.168.19981218135546.03717db0@localhost> Date: Fri, 18 Dec 1998 13:55:46 -0500 To: email@example.com From: Koen Holtman <Koen.Holtman@cern.ch> (by way of Henrik Frystyk Nielsen <firstname.lastname@example.org>) Subject: Re: Looking for comments on the HTTP Extension draft [...draft-frystyk-http-extensions-01...] [....] > >From: Keith Moore <email@example.com> [....] > > We haven't had time to do a detailed > >review ourselves, but we would like other folks' opinions as to > >whether this draft is reasonably complete (i.e. that it addresses > >enough aspects of the problem) and ready for standardization, > >before we do an official Last Call. As far as I can see the draft is reasonably sound as an extension to HTTP. Some more discussion of caching implications is needed though. There could be some more discussion of caching related considerations, in particular - I would like to see and example of correct use of the Vary header (hinted at in 3.1) - I would like explicit mention of the fact that things can break horribly if extensions are added to a 304 response. See http://lists.w3.org/Archives/Public/ietf-http-ext/1998JanMar/0105.html for a discussion of the problem. [On a related note: it is non-trivial to piggy-back something not directly related to the response body onto a HTTP/1.x response and have it work correctly through caches. Having it work and also be cache-friendly is _extremely_ non-trivial. This is one of the things I would like to see addressed in any future HTTP-NG/1.2/2.0 effort] Making responses to M-GET (or other mandatory methods) cachable is not as simple as it looks from the examples at the end of the draft. In the example of 15.1, all of the proxies in the chain will cache the response as a response to an M-GET request, and these cannot be used to respond to future GET requests on the same resource. Also, if the user agent would send a subsequent M-GET+Man request, it probably wants the Man header to reach the origin server, so it would have to include a Cache-Control: no-cache in its request. The only case where the cached response could do some good is if a proxy along the chain transforms a GET request into an M-GET+C-opt request, but this subtle benefit is not clear from the example. In short I would call the example in 15.1 misleading. Rather than examples encouraging people to put Cache-Control in M-GET responses, I would have a discussion of the subtle failure modes involved, and some simple, not necessarily cache-friendly, guidelines for avoiding all failure modes. With respect to the draft solving a problem, I will repeat some points I have made before elsewhere: - The header field prefixes stuff is just unnecessary complexity in my opinion. It would be easier for everyone to put all extension related data as decl-extensions in the Man or Opt header. - If the goal is to prevent clashes between header fields invented by independent developers (whether inside the IETF or outside it), an open header field registry would be far better at achieving this goal. (Weren't there efforts to set up such a registry? What happened to them?). The usual way for people to prototype an HTTP extension is to hack together a CGI script which emits or responds to a few newly invented headers. I can't see how the proposed mechanism would change this practice. The barrier of entry to using Man/Opt with a newly invented URI will always be slightly higher, as one has to implement parsing of the Man/Opt headers at least. Koen.