Re: draft-ieft-http-options-00.txt

    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?


Received on Friday, 8 August 1997 16:49:59 UTC