Re: Looking for comments on the HTTP Extension draft

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. Btw, I don't know if you have seen the
extended set of scenarios at

	http://www.w3.org/Protocols/HTTP/ietf-http-ext/Scenarios.html

although they do not contain a vary example.

>  - 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:

   If the conditional GET used a strong cache validator (see section
   13.3.3), the response SHOULD NOT include other entity-headers.
   Otherwise (i.e., the conditional GET used a weak validator), the
   response MUST NOT include other entity-headers; this prevents
   inconsistencies between cached entity-bodies and updated headers.

>   [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.

M-GET is semantically different from GET - the difference being exactly one
or more mandatory extensions. It therefore doesn't make sense to say that a
response to a M-GET request can be cached and served to another client
issuing a GET request.

>  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. However, as the semantics of the M-GET method
isn't defined by the M- prefix but rather by the extension declaration, it
can only be served by a cache who knows that extension.

>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.

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

> - 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?).

HTTP extensions has no problem working with centrally registered header
fields as long as they are referencable by a URI or in the special case of
being defined by a standards track RFC.

>  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.

The purpose of a framework is that you only have to implement it once and
then can reuse it as often you like. However, you are right that it has to
be implemented at least once but I can't see how that makes it differ from
any other feature in HTTP.

Henrik
--
Henrik Frystyk Nielsen,
World Wide Web Consortium
http://www.w3.org/People/Frystyk

Received on Friday, 18 December 1998 21:15:44 UTC