W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1997

Re: Comments on I-D ACTION:draft-ietf-http-options-02.txt

From: Koen Holtman <koen@win.tue.nl>
Date: Tue, 9 Sep 1997 23:08:40 +0200 (MET DST)
Message-Id: <199709092108.XAA02642@wsooti08.win.tue.nl>
To: Yaron Goland <yarong@microsoft.com>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/4381

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

Received on Tuesday, 9 September 1997 14:11:04 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:21 UTC