- From: Jeffrey Mogul <mogul@pa.dec.com>
- Date: Fri, 08 Aug 97 16:41:43 MDT
- To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
- Cc: mogul@pa.dec.com
I read through the I-D, thinking about how an origin server that
supports cookies (i.e., RFC 2109) might respond to
OPTIONS * HTTP/1.1
Compliance: rfc=2109
The problem is that (I believe) most of the support is not in the
server itself, but in CGIs. Consequently, the server software may not
be able to answer authoritatively about whether RFC 2109 is supported,
because that may depend on what each individual CGI does.
What advice would the authors (or others) give?
>From the point of view of the protocol, the client can't necessarily
tell if there's a CGI program involved, and if I wanted to be a
purist about things, I would say that this is well and good and
the right thing from a layered-architecture point of view. I.e.,
don't expose "implementation details" in the protocol design.
Of course, real life isn't so neat. It sounds like the best
approach would be to have Compliance supported in the interface
between the CGIs and the server per se, but in the absence of
that, I guess the best advice I can give is:
Don't claim compliance with things if, for this resource, a CGI
sub-program will be invoked and you're not sure if the
sub-program will screw things up.
on the theory that it is better to indicate non-compliance when
you might comply, than to claim compliance when you might not.
Nit: p.4, section 3.2: I think the phrase "originating sender" is
a poor one. From one perspective, the originating sender is the
client that initiated the request. But I think it's intended to mean
the server that responded to the OPTIONS method.
Right, I was looking for a phrase that mean "server that first sent
the OPTIONS reply", which could be different from the "origin server"
for the URI (e.g., because of Max-Forwards). Any suggestions for
a more precise short phrase? Or should we just use the long one?
-Jeff
Received on Friday, 8 August 1997 16:49:59 UTC