- From: Mark Nottingham <mnot@mnot.net>
- Date: Thu, 13 Nov 2008 17:38:22 -0800
- To: HTTP Working Group <ietf-http-wg@w3.org>
Does anyone object to reinstating this text into 2616bis? On 11/10/2007, at 11:43 PM, Mark Nottingham wrote: > > Now i83. > > <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i83> > > > On 04/10/2007, at 9:10 AM, Henrik Nordstrom wrote: > >> On ons, 2007-10-03 at 23:49 +0200, Julian Reschke wrote: >> >>> " If a proxy receives a request without any path in the Request- >>> URI and >>> the method specified is capable of supporting the asterisk form >>> of >>> request, then the last proxy on the request chain MUST forward >>> the >>> request with "*" as the final Request-URI. For example, the >>> request >>> >>> OPTIONS http://www.ics.uci.edu:8001 HTTP/1.1 >>> >>> would be forwarded by the proxy as >>> >>> OPTIONS * HTTP/1.1 >>> Host: www.ics.uci.edu:8001 >>> >>> after connecting to port 8001 of host "www.ics.uci.edu"." -- >>> <http://tools.ietf.org/html/rfc2068#section-5.1.2> >>> >>> Best regards, Julian >> >> There is one slight problem with the above and it's " and the method >> specified is capable of supporting the asterisk form of request". >> This >> requires the proxy to know about each such method, and with HTTP >> being >> extensible it's not fully possible. In RFC2616 only OPTIONS meets >> this >> criteria. >> >> Is there a possibility for other methods than OPTIONS which may make >> sense on a global resource-less context? I think not. If this is >> complemented with a restriction that the special request-URI "*" may >> only be used in OPTIONS requests then it's fine. Interoperability of >> extension methods using "*" will be tricky at best.. >> >> Please put this into the issues list, starting with julians response. >> http://www.w3.org/mid/47040E65.9070001@gmx.de >> >> >> Regards >> Henrik > > > -- > Mark Nottingham http://www.mnot.net/ > > -- Mark Nottingham http://www.mnot.net/
Received on Friday, 14 November 2008 01:39:02 UTC