Re: Solution to the CGI message trap

>The CGI problem of accepting (returning 200 OK) to arbitrary methods is a
>very serious problem and we need a solution urgently in order to be able to
>extend HTTP beyond GET, HEAD, PUT, and POST.
>
>Currently, you can't even do a DELETE and know that it works even if you
>get 200 OK back which means that neither HTTP/1.1, nor DAV nor Mandatory
>can be used reliably.

Sure they can, just not with unreliable resources.  Keep in mind that
there is nothing preventing the server from lying to the client, nor
are CGI apps the only broken gateway application (Harvest and Squid
have always been broken in many ways HTTP).  We have two choices:
either assume they are broken and broken things will happen due to
the fault of the server owner for installing broken software, or
force the code into a positive-acknowledgement situation that cannot
be duplicated by unintentionally broken code.

Note that CGI itself is not broken -- CGI has always required that the
script check the method before responding.  The problem is that most
of the example CGI scripts don't.  Actually, the server really should
be adding a Via entry for the CGI version, but I forgot to do that
in Apache.

Jeff's Ack response will probably work, provided you don't mind that
none of the responses will ever be cachable.  It is hard to tell if
anyone would want a mandatory extension to be cachable, so I don't
know if that is good or bad.  For that matter, I have yet to see a
scenario where mandatory extensions are needed at all that didn't also
require some outside knowledge, perhaps obtained from a prior request,
about the resource in question.

My opinion is that you should trash all these funky additions to HTTP
and just define a single, non-repudiable OPTIONS request with a response
that contains an Ack.  What you are trying to do is not sensitive to
the performance hit of an extra round trip, so why add all this baggage
just to avoid it?

Other than that, I'd have to say that I don't care whether a DELETE
does or does not have an effect on a broken CGI script.  Obviously
the person installing that script hadn't intended it to be subject
to deletion via HTTP, and the person running the agent that performed
the DELETE action obviously didn't have a clue as to what they were doing.
It is this type of disconnect that the protocol should just punt on and
simply rely on outside human action to resolve the problem.

  [Note: For a WebDAV server, a real DELETE on the CGI script would
   be on a different URL than that used by existing GET/POST references,
   so this won't be an interoperabilty problem in general.]

OTOH, you could add a bunch of checks and double-checks to the
mandatory stuff so that it isn't worth implementing even for the
resources that would have understood it.  That is why perfection
is not one of the goals of HTTP.

....Roy

Received on Friday, 7 August 1998 21:31:44 UTC