W3C home > Mailing lists > Public > ietf-discuss@w3.org > January 1999

Re: Looking for comments on the HTTP Extension draft

From: Koen Holtman <koen@win.tue.nl>
Date: Tue, 5 Jan 1999 13:42:19 +0100 (MET)
Message-Id: <199901051242.NAA24950@wsooti13.win.tue.nl>
To: frystyk@w3.org (Henrik Frystyk Nielsen)
Cc: Koen.Holtman@cern.ch, new-httpd@apache.org, discuss@apps.ietf.org, ietf-http-ext@w3.org, moore@cs.utk.edu
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.
Received on Tuesday, 5 January 1999 07:45:41 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 23 March 2006 20:11:25 GMT