- From: Koen Holtman <koen@win.tue.nl>
- Date: Tue, 9 Sep 1997 23:08:40 +0200 (MET DST)
- To: Yaron Goland <yarong@microsoft.com>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
In general, I find myself agreeing to most of the comments Yaron made on the draft. I too think that `the whole server' is an empty concept. It may make some sense for proxy servers, but not for origin servers. Also the language of the draft in places like "a subprogram outside the control of the server itself (such as a CGI application)" clashes with HTTP/1.1 terminology. According to 1.1, a server is everything including its CGIs, so some new terminology is needed if distinctions inside the server are to be introduced. I am not very happy with the RFC= and HDR= method of labelling server features. The draft asserts that `the meaning of an RFC is both well-defined and (more important) immutable.'. This may be true, but for an RFC which defines three levels of compliance, like DAV does I believe, the defined syntax is insufficient for capturing all well-defined levels of this well-defined meaning. Also, the HDR= syntax has the problem that multiple RFC's may define different versions of an extensible header. If HTTP/1.2 defines three new cache-control keywords, then HDR=cache-control becomes ambiguous. Also, what does it mean if a server says that it does not support, for example, the if-modified-since header? Does this mean that the server does not support conditional gets, or does it mean that sending an if-modified-since header to it may lead to incorrect results? I do not think that the RFC= and HDR= problems can be solved by adding more details to the syntax, or by switching to XML syntax. I think that the only way out is to set up a registry for feature labels, whose meaning is defined unambiguously by the registry entries. Other comments: On the issue of merging the Options draft with the 1.1 spec: I think this is a bad idea because it would delay the 1.1 spec too much. I'd rather see the options draft progressing separately (or not progressing at all). I would not like to be put into a position where I end up being screamed for delaying 1.1 over fixing flaws in the merged Options part. I'll repeat what I said in Munich: I do not agree with the claim in the draft that `there exists an immediate need to define a simple and well-specified OPTIONS mechanism for HTTP/1.1.' If we end up putting proxy redirects, which currently use Options, in 1.1 (and I don't think we should) I'd rather put in a special-purpose mechanism for doing the feature discovery which is needed for proxy redirect security. About the Public header: is this header actually being sent by any existing server? The addressing mechanism in the options draft does not allow me to address the proxy if I have a (CERN) server which is both an origin server and a proxy on the same port. So the sentence `This allows the sender to select the Nth proxy on a path, without knowing its hostname.' is wrong. The spec does not define clearly enough what a server should send in a (Non-)Compliance header if it does not know whether it complies. The language about this is too distributed over the whole spec, and I cannot tell if it covers all cases. In the Non-Compliance header, there should be a way for a proxy to use an alias, like in the Via header. The spec says that, in proxies, `presumably any request using an unsupported method would immediately be rejected.' I do not think this is the case, in fact I think that existing proxies would just relay the request towards the origin server, maybe switching to tunnel mode. I think this is at least what 1.1 encourages them to do. In the security considerations section, add the consideration that options discovery makes attacks based on known security holes easier, and harder to detect. I do not think that there is a strong enough case for adding all the complexity which is currently present in the Options draft to the load of 1.1 server implementers. I do not know whether the draft intends to require an origin server know whether all possible HDRs and RFCs are supported or not by its server core. But if the draft does, I would object to it because this requires server core authors to waste lots of time writing and maintaining tables of headers and rfcs, with most of the table entries never being queried. I would prefer a mechanism in which the server implementer only needs to keep tables of those things for which it makes sense, in his opinion, to do an options request. Koen.
Received on Tuesday, 9 September 1997 14:11:04 UTC