Re: Solution to the CGI message trap

>    This would be exactly my point ... if a new method is sent to a
>    server which doesn't support the application which uses the new
>    method, so what?  Brain dead client application gets what it
>    deserves ... a brain dead response.
>    
>Right.  But the problem remains, how is the client supposed to know
>whether or not the server supports the application in question?  

The client gets back a 200 response consisting of what the CGI script
would have sent for a GET.  This is easily distinguishable by a human
user, which is the only agent that has the right to understand whether
it succeeded or not.

>One major strength of the Web is that clients and servers do not have to
>come from the same team in order to play together, but this breaks down
>if we have to assume some mystical out-of-band mechanism for
>determining whether an application is "supported".  It makes sense for
>HTTP-EXT to come up with a simple, relatively efficient, and (most
>important of all) 100% reliable means for a client to test its belief
>about a server.

Sure, define an OPTIONS request which does that.  That is both simple
and relatively efficient, far more so than adding overhead to every
request that will ever need the feature within an environment that
isn't screwed over by broken software that would just ignore it anyway.

If any of this were the normal case, or even a realistic scenario,
it might be worth special hoops in the mandatory spec.  But it isn't
the normal case for the user to be performing mandatory request on
a resource that doesn't check the method before acting on the request.
The problem is not that the protocol is incomplete -- its that the
other party is not following the protocol at all.

....Roy

Received on Tuesday, 11 August 1998 06:53:52 UTC