Date: Fri, 18 Dec 1998 14:53:10 +0100 (MET)
From: Koen Holtman <Koen.Holtman@cern.ch>
To: new-httpd@apache.org
cc: Koen Holtman <Koen.Holtman@cern.ch>, discuss@apps.ietf.org,
  frystyk@w3.org, ietf-http-ext@w3.org, moore@cs.utk.edu
Subject: Re: Looking for comments on the HTTP Extension draft
In-Reply-To: <3.0.5.32.19981217133844.03002de0@localhost>
Message-ID: <Pine.GSO.3.95a.981218120738.24381D-100000@cms1>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: new-httpd-owner@apache.org
Precedence: bulk
Reply-To: new-httpd@apache.org


[...draft-frystyk-http-extensions-01...]

[....]
> >From: Keith Moore <moore@cs.utk.edu>
[....]
> >  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.