From: email@example.com (Koen Holtman) Message-Id: <199901151315.OAA23634@wsooti08.win.tue.nl> To: firstname.lastname@example.org (Henrik Frystyk Nielsen) Date: Fri, 15 Jan 1999 14:15:48 +0100 (MET) Cc: email@example.com, 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 13:42 1/5/99 +0100, Koen Holtman wrote: [...] >>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. > >It's actually more a question of specification independence. No, it is a question of whether your spec is clear enough. > Anybody can >extend HTTP/1.1 - and while doing that they may run into the problem of how >to handle 304 messages. This is not unique to the extensions draft. The >important thing to note is that the extension draft doesn't invalidate >existing HTTP/1.1 behavior and so if you follow HTTP/1.1 rules, you should >be safe. Yes, the special status of 304 will be a problem in many HTTP extensions implementations, but that does not mean that you can just remain silent about it in your particular extension spec. If we had some generic document which discussed the problem in a generic way, you could get away with just referencing that document in your spec, but there is no such document. >>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. > >Before doing that I would like to understand what you think is wrong with >the current model and how that affects caching. I don't think there is anything wrong with the extension mechanism itself, I just think that the current examples are not very good. They steer implementers in a certain direction (making responses cachable) without mentioning the pitfalls along the way. I'd rather see clear instructions on how to follow a safe path. >Sorry for being slow but I >really don't think this belongs in the extension draft. [...] >>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. > >Nope, it wants some action to be performed by a server which is authorized >to and capable of handling the request. The trouble is that if the client sends the request from table 3 a second time before the previous response has expired: Client issues a M-GET <some-address> HTTP/1.1 request with one Opt: <ext-1> optional and one Man: <ext-2> mandatory ... extension then an intermediate cache may return the fresh response HTTP/1.1 200 OK Cache-Control: max-age=120, no-cache="Ext" Age: 123 ... [Note no Ext: in the response!] in which case *no* mandatory action has been performed by an authorised and capable server. If it wanted to make sure that such an action would be performed, the client would have to send M-GET <some-address> HTTP/1.1 Opt: <ext-1> Man: <ext-2> Cache-Control: no-cache but this is not apparent from your examples. So either the client in the example is not really interested in having the action performed, or the example shows a broken way of controlling the caches. > The opening statement in section 5 >clearly defines this: > > A server MUST NOT claim to have fulfilled a mandatory request > unless it understood and obeyed all the mandatory extension > declarations in the request. This section defines a > mechanism for conveying this information to the client in > such a way that it interoperates with existing HTTP > applications. > >Note that it doesn't say "origin server" but any server. So the second 'end' in the man 'end-to-end' declaration does not mean the origin server? This is not at all clear to me from reading your spec. In HTTP/1.1 'end to end revalidation' means revalidation which goes through to the origin server, so I was assuming that an 'end-to-end' declaration also goes through to the origin server. The above quote talks about both end-to-end and hop-to-hop, so it does not contradict the assumption that end-to-end always means to the origin server. >Henrik Koen.