From: firstname.lastname@example.org (Koen Holtman) Message-Id: <199901051242.NAA24950@wsooti13.win.tue.nl> To: email@example.com (Henrik Frystyk Nielsen) Date: Tue, 5 Jan 1999 13:42:19 +0100 (MET) Cc: Koen.Holtman@cern.ch, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com Subject: Re: Looking for comments on the HTTP Extension draft Henrik Frystyk Nielsen: > >At 14:53 12/18/98 +0100, Koen Holtman wrote: > >>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) > >It works exactly as for accept* headers with q-values in case you are using >ns and without q-values if not. I am not sure what you are saying here, I don't see the connection with the presence or absence of q values. Anyway, the type of example I want to see is request: M-GET /p/q HTTP/1.1 Man: "http://www.x.y/transform"; ns=16- 16-use-transform: xyzzy .... response: HTTP/1.1 200 OK Ext: Vary: man, 16-use-transform Date: Sun, 25 Oct 1998 08:12:31 GMT Expires: Sun, 25 Oct 1998 08:12:31 GMT Cache-Control: no-cache="Ext", max-age=100000 .... [....] >> - 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. > >I don't think the situation you describe is any different than what can >happen if any header field is tagged onto a 304 response. This is the >reason for the restrictions on what a 304 response can contain, see > > http://www.ietf.org/internet-drafts/draft-ietf-http-v11-spec-rev-06.txt > >section "10.3.5 304 Not Modified", where it says: I know about that restriction on 304 responses in HTTP/1.1. But it is not clear from your http-ext spec whether http-ext servers and proxies may violate that restriction. http-ext proxies violate 1.1 in other ways too, for example proxies will sometimes change the request method, which is not allowed under plain 1.1. You need to be more explicit on the matter of 304 responses. It is true that one could conclude, after careful analysis of caching scenarios, that this 304 restriction in HTTP needs to be retained, but it is far too easy to wrongly infer from the text that the piggybacking mechanism is safe for any response code. I guess there is a common theme in my Vary and 304 comments and your responses: I want things to be more obvious, and you are saying that things are obvious enough already. I believe that the current draft, if used as a basis for implementations, will quite likely lead to implementations which have subtle caching related problems. You may say that this is a fault in the implementers, who should have known the pitfalls in HTTP caching better, but I say this is a fault in the draft. I would be far happier if the draft dropped the examples with cachable responses and replaced it with a discussion of one fail-safe method of making sure that interference from caches is avoided. I would not care if the method was not very cache-friendly, expert implementers could figure out more cache-friendly methods for themselves. >> 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. > >Nope - by default, an HTTP client is interested in the nearest fresh >response it can get for that method. It is no different with a client >issuing a M-GET request - by default it is interested in the nearest fresh >response for that method. I disagree. If the client includes a Man header, it wants some action, specified by the extension in the header, to be performed by the origin server. Isn't that what mandatory stands for? If it did not really want the action, but would settle for a fresh response instead, it would have put the action in an Opt header. If mandatory means 'this request must result in an action by the origin server but a fresh response from a cache is OK too' then we are talking about a different type of extension mechanism I think. >> - 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. > >This proposal was voted down after discussion on the <ietf-http-ext> >mailing list: > > http://lists.w3.org/Archives/Public/ietf-http-ext/1998AprJun/0029.html Hmm, I did not recall that this issue was completely resolved, but I think I was wrong. The above URL points to the minutes of a phone conference I did not participate in, but looking a bit further in the list archives I guess the issue did get resolved on the list, by lack of comments to the last call. So I apologise for having brought it up again. [...] >Henrik Koen.