- From: Rodent of Unusual Size <Ken.Coar@Golux.Com>
- Date: Sat, 08 Aug 1998 09:09:15 -0400
- To: Henrik Frystyk Nielsen <frystyk@w3.org>
- CC: ietf-http-ext@w3.org, lawrence@agranat.com, paulle@microsoft.com
Henrik Frystyk Nielsen wrote: > > 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. I must be missing something here. CGI allows the script to return whatever status it likes, so why wouldn't a script return one appropriate to the success/failure of the operation it was asked to perform? As far as DELETE goes, how would CGI even get involved? DELETE is instructing the server to delete the resource identified by the URI, not return it -- so if the URI identifies a script it's not going to be invoked, and so CGI doesn't enter into it. > I CAN'T FIND ANY REALIABLE WAY TO DO THIS WHICH INCLUDES 1.0 PROXIES!!! Looking at your examples I still don't see the problem based upon my statement above, so I must definitely be missing something. I can't see why a DELETE transaction would be cached at all, particularly since 2068 says they mustn't be. But then I'm not really up on the proxy and caching issues; I'm just weighing in here because CGI is involved. FWIW, some of us *are* working on formalising CGI/1.1 and designing CGI/1.2; see <http://Web.Golux.Com/coar/cgi/>, such as it is. (Beware, that server will be going down Monday for about a week as it relocates.) If there's something CGI can/should do for this, please let us know so we can discuss and possibly include it. The mailing list is closed for anti-spam, so don't send anything to it without subscribing.. #ken P-)} Ken Coar <http://Web.Golux.Com/coar/> Apache Group member <http://www.apache.org/> "Apache Server for Dummies" <http://WWW.Dummies.Com/
Received on Saturday, 8 August 1998 09:24:23 UTC