Re: OPTIONS issues from Koen

I haven't been paying full attention to this discussion, but it
seems to be getting bogged down in the same conceptual issues as
we were facing back in September.

In particular, when the client finds something out about the
server, does this apply to
	the server implementation
	the server in its role as a "Web server" or "proxy server"
	the CGI scripts running on the server
	the specific resource
	the CGI scripts implementing the specific resource
	a proxy when forwarding requests
	a proxy when using entires from its a cache

or some combination of the above range of roles?

My opinion is that we are going to have continual confusion
(and a complex/unwieldy and potentially useless) extension protocol
if we try to pick some subset of this range of roles and
define the protocol around any particular set of "roles".

Maybe the right approach is to focus on a resource-by-resource
basis.  I.e., don't try too hard to define a protocol that
works like

	OPTIONS * HTTP/1.1
	Host: foo.com

to find out about what options foo.com supports, because this is
too broad a question to be meaningfully answered.

Instead, perhaps we should be happy if the client can know
what options the server supports for a specific method on a
specific resource (or just possibly on a specific collection
of resources, such as in DRP or WEBDAV).  While this might
introduce some inefficiency into the protocol (extra round
trips, primarily) that might be a reasonable price to pay
for a simple, and widely implemented, mechanism.

In draft-ietf-http-options-02.txt, back in September, we
proposed a "Compliance" header that one could tack onto
any request, so that the client could find out about the
options supported for any specific request (including, if
necessary, those supported by a CGI script used in processing
the request).  However, I didn't really address the issue
of "entire server" vs. "specific resource" in that I-D.

Similarly, in the "Mandatory" I-D (draft-frystyk-http-mandatory-00.txt),
while it may have other problems, it does follow a similar model:
it applies to requests/responses for specific resources, rather
than to an entire "server".  (Again, this distinction is not really
explicitly discussed in the mandatory-00 I-D.)

Can someone describe a scenario where it is essential (not
just a performance issue, but a correctness one) to be able
to find out what options a "server" (or "proxy") supports
with respect to a multiplicity of resources, rather than just
with respect to a single resource (and perhaps w.r.t. a specific
method on that resource?)

I'll certainly grant that it adds round-trips if we insist
that a client test options on a per-resource basis.  There
might be some solace in realizing that many resources are
re-accessed by the same client, and presumably a server's
capabilities w.r.t. a specific resource/method pair usually
don't change (and so wouldn't add extra RTTs after the first
use).  One might also come up with relatively simple schemes
to say "you asked about this resource, but my answer applies
equally to this other set of resources".  But if the server's
answer *might* be different for each individual resource,
then I think it will be very hard to define a protocol
that works well when the client asks about "*".

I.e., rather than this:

  request:
	OPTIONS "*" HTTP/1.1
	host: foo.com

  response:
	HTTP/1.1 599 I have no way to answer that question generically

we could have something like this:

  request:
	GET /bar.html HTTP/1.1
	host: foo.com
	Compliance: RFC6789, RFC4567

  response:
	HTTP/1.1 200 OK
	Compliance: RFC6789, RFC4567
	Compliance-also-applies-to: url="*";methods={GET,HEAD}

leaving it up to the server (which knows better than the client)
whether it makes sense to even discuss options regarding "*".

-Jeff

Received on Monday, 2 March 1998 14:24:06 UTC