Re: Server-side roles in the HTTP

Mark Nottingham:
>
>As you may be aware, I have submitted an Internet-Draft,
>draft-nottingham-http-roles-00.txt.
>
>I'd very much appreciate comments from the http-wg, as I see it as primarily
>in that domain (with some overlap to wrec and the cgi efforts).

I read the draft; I won't give specific comments, just some high level
observations.

With my http-wg background, it looks like the draft mixes two things
that I would rather see covered separately.  On the one hand, there
are a lot of efficiency requirements, which, if not followed, won't
affect protocol-level correctness as such.  I'll stay silent on these
as there has been a lot of discussion about them already.

On the other hand, there are a few things that do have an impact on
the ability of a CGI author to produce correct HTTP/1.1 responses.  An
example is the requirement in section 6.2 that validators must be
passed through without modification.

Some time ago I updated the Apache mod_negotiation to HTTP/1.1 and TCN
compliance.  While doing this I encountered several cases where the
current CGI specification does not define server behavior, and where
having a defined behavior would greatly help CGI authors in being more
HTTP/1.1 friendly/compliant.  I'm saying CGI specification here but
this observation really extends to all CGI-like interfaces where
application code supplies headers and and a response body to the
server.

It occured to me that the CGI specification would benefit from a few
HTTP/1.1 targeted extensions and updates.  These extensions have
little to do with performance directly, but more with protocol and
cache correctness, which of course does affect performance on a higher
level.  Updating the CGI specification for HTTP/1.1 is _way_ down on
my todo list however, so I doubt I'll ever get around to doing it.  Of
course, with sufficient encouragement and offers to share the
workload, this item may move higher on my todo list.

In any case, as an example of the kind of things I would want a
1.1-oriented CGI update to define, here is is the type of facility I
would prefer that a server provides with respect to HTTP/1.1 entity
tags:

  The server should *not* pass from the CGI interface into the
  HTTP/1.1 response unchanged!  Rather, by default, the CGI script
  should be able to return a `content validator' to the server, which
  will be used by the server as _one_ of the components of the
  HTTP/1.1 entity tag.  Another component is a server-generated
  validator for the script file itself.  Thus, if the script is
  updated, correct cache resynchronisation is guaranteed.  If the
  response body output by the script is not used directly as a HTTP
  response body, but in stead embedded in other content before being
  sent to the client, then the entity tag should also act as a
  validator for the other content.  Naturally, the server, not the
  script, is responsible by default for correctly processing HTTP/1.1
  if-none-match and if-match header fields.

Note that Apache, for example, currently does not do much of the above
at all.  Therefore, as a CGI script writer for Apache I would not
currently create scripts that emit entity tags.  Not emitting these
tags is the safest route to HTTP/1.1 compliance.

With respect to draft-nottingham-http-roles-00.txt, I would conclude
that it either needs to separate out the CGI extensions that help CGI
authors in producing correct HTTP/1.1, or drop such extensions
alltogether.

Koen.

Received on Monday, 20 September 1999 03:04:51 UTC