W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2014

Re: draft-ietf-httpbis-http2-latest, 8.1.2.1 Request Header Fields | Re: draft-ietf-httpbis-http2-latest, 8.1.2.1 Request Header Fields | Re: draft-ietf-httpbis-http2-latest, 5.5 Extending HTTP/2

From: Roy T. Fielding <fielding@gbiv.com>
Date: Thu, 24 Jul 2014 10:36:02 -0700
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <99DDCC5E-FF8A-4311-A1A9-4A29CAEC7C41@gbiv.com>
To: Martin Thomson <martin.thomson@gmail.com>
On Jul 24, 2014, at 10:26 AM, Martin Thomson wrote:

> On 24 July 2014 10:18, Julian Reschke <julian.reschke@gmx.de> wrote:
>> I believe this is right, but it seems to me we really need a set of examples
>> to make sure we got everything right.
> 
> 
> My question, that I think requires a little more proxy chops than I
> have is this:
> 
> What is the form of an options request to a given origin when directed
> to a proxy:
> 
>   OPTIONS * HTTP/1.1
>   Host: example.com:80
> 
> 
>   OPTIONS http://example.com:80* HTTP/1.1

No, it is

  OPTIONS http://example.com:80 HTTP/1.1

> Reading RFC 3986 it appears that the following is ambiguous, because
> '*' is a valid part of the reg-name construction:
> 
>   OPTIONS http://example.com* HTTP/1.1
> 
> That suggests the former variant is the only valid form.

The * is not sent in the request to the proxy, which is why we have that
rule saying a proxy translates the empty path on OPTIONS to a "*" when
forwarding the OPTIONS request to the indicated origin server.

....Roy
Received on Thursday, 24 July 2014 17:36:25 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 09:57:09 UTC