RE: OPTIONS and TRACE vis a vis CGI applications

I think a compelling case can be made for passing OPTIONS to CGI
programs.  I always try to check the method in my CGI programs, but I
don't doubt that there are a lot of them out there that don't. Still, my
hard-nosed approach is that CGI programs are really sub-servers and have
just as much of an obligation to comply with the protocol as any
servrer. (Okay, okay, maybe "obligation" isn't the right word.)

This obviously isn't an IETF issue, but it seems to me that a reasonable
strategy would be for servers to only pass GET and POST requests to a
CGI program unless some affirmative action is taken (e.g., via
.htaccess) to indicate that they can properly handle other requests.

==
Gregory Woodhouse <gregory.woodhouse@med.va.gov>
San Francisco CIO Field Office - Infrastructure
+1 415 744 6362
Standards are wonderful; everyone should have one of their own.


> ----------
> From: 	Jeffrey Mogul[SMTP:mogul@pa.dec.com]
> Sent: 	Thursday, March 12, 1998 12:04 PM
> To: 	http working group
> Subject: 	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 Monday, 16 March 1998 21:53:00 UTC