- From: Koen Holtman <koen@win.tue.nl>
- Date: Mon, 20 Sep 1999 11:59:54 +0200 (MET DST)
- To: Mark Nottingham <mnot@mnot.net>
- Cc: http-wg@hplb.hpl.hp.com, Koen Holtman <koen@win.tue.nl>
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