Re: OPTIONS and TRACE vis a vis CGI applications

Scott Lawrence wrote:
    On Wed, 11 Mar 1998, David W. Morris wrote:
    
    > It is my sense from list postings that a TRACE or OPTIONS request which
    > referenced a specific resource which a server handed to an external
    > application such as a CGI program should be handed to that program 
    > for handling.
    > 
    > That is:
    >    OPTIONS /cgi-bin/somescript HTTP/1.1
    > or
    >    TRACE /cgi-bin/somescript HTTP/1.1
    > should be handled by the application which would respond to a GET or HEAD
    > of the same resource.
    
    I would agree for OPTIONS, since it is probably the capabilities of
    the CGI or other sub-server that the requestor is interested in
    (although my experience has usually been that CGIs often respond as
    though the method were GET or POST because the authors don't
    check).

    I can't think of any reason why TRACE would require the
    participation of the resource - it's purpose is just to reflect the
    headers as received, and the server itself can do that just fine.

Note that the spec, in section 9.1.2 (Idempotent Methods) says

	Also, the methods OPTIONS and TRACE should
	have no side effects, and so are inherently idempotent.

(I'm not sure if that "should" should be a "SHOULD" or a "MUST",
or if it just means "normally.")

Later, in 9.2 (OPTIONS) the spec says:
    This method allows the client to determine the
    options and/or requirements associated with a resource, or the
    capabilities of a server, without implying a resource action or
    initiating a resource retrieval.

And in section 9.8 (TRACE) the spec says:
    The TRACE method is used to invoke a remote, application-layer
    loop-back of the request message.

The implication seems to me that the spec doesn't care if the
CGI (or other sub-server) is invoked for TRACE or OPTIONS ...
but you can't let this invocation cause any side-effects.

I'm not sure whether the CGI specification is sufficient
to guarantee that if the method is OPTIONS or TRACE, then
the CGI script will never cause side-effects.  So it would
seem to me that a cautious implementation of TRACE, at least,
wouldn't risk invoking the CGI script.

E.g., if the client sends

	TRACE /cgi-bin/action=buy&stock=sunw&quantity=100000 HTTP/1.1
	Host: stockbroker.com

I think it would be a mistake to excecute the CGI script.

It's trickier with OPTIONS, since the capabilities of the CGI script
might be the target of the OPTIONS request.  I suspect this means
that we're not done figuring out how OPTIONS is supposed to work ....

-Jeff

Received on Thursday, 12 March 1998 12:08:05 UTC