Subject: Re: draft-ietf-httpbis-http2-latest, 5.5 Extending HTTP/2

From: Martin Thomson <[email-masked]>
Date: Fri, 11 Jul 2014 10:34:43 -0700

On 11 July 2014 08:45, Kari Hurtta <[email-masked]> wrote:
> » HTTP/2 permits extension of the protocol. Protocol extensions can be
> » used to provide additional services or alter any aspect of the
> » protocol, within the limitations described in this section. Extensions
> » are effective only within the scope of a single HTTP/2 connection.
>
> So proxy which uses HTTP/2 both downstream and upstream, must clear
> are  unknown or unsupported values before forwarding to
> upstream or downsream. (That means that reserved fields or bits
> are put to default values given on this documentation. )
> And proxy must discard unknown or sunsupported frames.

This is correct.  Bits that the proxy doesn't know about (like flags),
can't be copied across.

In other words: no extension smuggling.

> » Implementations MUST ignore unknown or unsupported values in all
> » extensible protocol elements. Implementations MUST discard frames that
> » have unknown or unsupported types.
>
> I read that "MUST ignore" that these unknown or unsupported values
> are not read by proxy and when packet is generated to upstream or
> downstream default values are used for reserved fields.

That's right.  If someone sets a setting that you don't understand,
even if you are just copying stuff into another session, don't
advertise that setting.  If someone sets a flag you don't understand,
don't copy that across.  You might be signing on to something you
don't understand.

>    +--------------------+
>    |  WWW server        |
>    +--------------------+
>            |
>          HTTP/2
>            |
>    +--------------------+
>    |      proxy         |
>    +--------------------+
>            |
>          HTTP/2
>            |
>   +--------------------+
>   |  WWW browser       |
>   +--------------------+
>
>
> So here WWW server and WWW browser can not communicate
> with using any extension which is not supported by proxy
> even when extension does not change semantics of existing
> protocol components.

Yeah, proxies will have that effect.  Preventing that sort of
communication is often a goal of a proxy.

---

From: Yutaka Hirano <[email-masked]>
Date: Mon, 14 Jul 2014 10:46:27 +0900

> don't copy that across.  You might be signing on to something you

Is that same for colon-started headers?
i.e. Must a proxy filter out colon-started headers that it doesn't
understand?

Thanks,

---

From: Martin Thomson <[email-masked]>
Date: Mon, 14 Jul 2014 09:36:01 -0700

On 13 July 2014 21:42, Kari Hurtta <[email-masked]> wrote:
> Next text does not require filtering out colon-started headers:

I haven't merged it yet, but it's here:
https://github.com/http2/http2-spec/pull/546

---

From: Martin Thomson <[email-masked]>
Date: Mon, 14 Jul 2014 13:40:00 -0700

On 14 July 2014 13:09, Kari Hurtta <[email-masked]> wrote:
>
> So it is implied (but not said) that implementations MUST NOT generate
> undefined pseudo-header fields.

The doc says:

"Implementations MUST NOT generate header fields that start with a colon"

How is that ambiguous?  Would you prefer "endpoint" over
"implementation"?  Is that it?

---

From: Martin Thomson <[email-masked]>
Date: Tue, 15 Jul 2014 10:13:31 -0700

On 14 July 2014 22:52, Kari Hurtta <[email-masked]> wrote:
> Got it ?

Oh, really?  Sure.
https://github.com/http2/http2-spec/commit/313c034c913d23beaef66fed309064a451f467aa

---

From: Martin Thomson <[email-masked]>
Date: Wed, 16 Jul 2014 10:08:50 -0700

On 15 July 2014 23:33, Kari Hurtta <[email-masked]> wrote:
> Should this
>         "other than those defined in this document"
>
> to be
>         "other than those defined in this document or extensions (Section 5.5)"

We decided to forbid the use of colon-headers in extensions.

> In other hand I think that this whole text
>
> » Header field names that start with a colon are only valid in the HTTP/2 context. These are not
> » HTTP header fields. Endpoints MUST NOT generate header fields that start with a colon other
> » than those defined in this document [or extensions (Section 5.5)]
>
> belong to
>
> 8.1.2 HTTP Header Fields

Let's see: https://github.com/http2/http2-spec/commit/cf1677cbc2b8f501204de18ecfe6ff4be623b9ba

---

From: Yutaka Hirano <[email-masked]>
Date: Thu, 17 Jul 2014 10:38:36 +0900

I see.
Currently I would like to use SETTINGS frames to confirm the WS-over-HTTP/2
capability of a communication channel, like this.

An endpoint sends a SETTINGS frame with WS_CAPABLE once a HTTP/2 connection
is created.
An endpoint knows that an HTTP/2 connection is capable of WS_OVER_HTTP/2 if
it receives a SETTINGS frame with WS_CAPABLE.
A client knows that an HTTP/2 connection isn't capable of WS_OVER_HTTP/2 if
it receives a Websocket handshake response before receiving a SETTINGS
frame with WS_CAPABLE.
A server knows that an HTTP/2 connection isn't capable of WS_OVER_HTTP/2 if
it receives a Websocket handshake request before receiving a SETTINGS frame
with WS_CAPABLE.

Martin, does that look correct to you?

Thanks,

On Thu, Jul 17, 2014 at 2:08 AM, Martin Thomson <[email-masked]>
wrote:

> Let's see:
> https://github.com/http2/http2-spec/commit/cf1677cbc2b8f501204de18ecfe6ff4be623b9ba
>

---

From: Martin Thomson <[email-masked]>
Date: Wed, 16 Jul 2014 20:39:50 -0700

> Martin, does that look correct to you?

In this case, it's probably sufficient to rely on the server
indication alone, since the client is going to be the one doing the
indication.  At that point, game on.

There's some advantage in having the ALPN tag here, because you avoid
the extra round trip, but that's something I'll leave you to ponder.

---

From: Yutaka Hirano <[email-masked]>
Date: Thu, 17 Jul 2014 14:54:35 +0900

Thank you for the feedback!
I am updating my WebSocket over HTTP/2 draft to reflect recent changes to
the HTTP/2 spec and any comments are welcome.

So I guess that Websocket handshake response is a HEADERS frame.
> Because new colon-headers was not allowed in extensions, I guess that
> this handshake is regular HTTP-header.
> ( And I suppose that Websocket handshake request must be HEADERS frame
>   because that is used to open new stream on HTTP/2. [*] )

Yes, handshake request and response use usual HEADERS frames.
The server knows that the client wants to establish a WebSocket connection
from
:scheme header (which is a standard colon header).
We can define usual headers for handshake without violating the HTTP/2 spec,
like sec-websocket-protocol in the native WebSocket.

But it is needed to confirm that intermediaries understand WebSocket over
HTTP/2.
That's why SETTINGS frames with WS_CAPABLE is needed.

Does that make sense?

On Thu, Jul 17, 2014 at 2:37 PM, Kari Hurtta <[email-masked]>
wrote:

> [ Date: Thu, 17 Jul 2014 10:38:36 +0900
>   From: Yutaka Hirano <[email-masked]>
>   To: Martin Thomson <[email-masked]>
>   cc: Kari Hurtta <[email-masked]>,
>                 HTTPBIS working group mailing list <[email-masked]>
> ]
>
> Yutaka Hirano <[email-masked]>: (Thu Jul 17 04:38:36 2014)
> > I see.
> So I guess that Websocket handshake response is a HEADERS frame.
> Because new colon-headers was not allowed in extensions, I guess that
> this handshake is regular HTTP-header.
>
> ( And I suppose that Websocket handshake request must be HEADERS frame
>   because that is used to open new stream on HTTP/2. [*] )
>
> If handshake response is some new frame type, then already receipt of a new
> frame type guarantees that endpoint (and whole chain of intermediaries and
> server)
> are capable of WS_OVER_HTTP/2.
>
> As per
>
> 5.5 Extending HTTP/2
> http://http2.github.io/http2-spec/#extensibility
>
> intermediaries does not "forward" unknown frame types (and of course does
> not
> send SETTINGS frame with unknown settings to upstream).
>
> ( Also if hanshake was reserved bits, then already presence of these
>   guarantee that endpoint are capable of WS_OVER_HTTP/2. But there
>   is not many usefull reserved bits on
>
>   4.1 Frame Format
>   http://http2.github.io/http2-spec/#FrameHeader
>
>   and not any on
>
>   6.2 HEADERS
>   http://http2.github.io/http2-spec/#HEADERS
>
>   I do not see that
>
>   5.5 Extending HTTP/2
>   http://http2.github.io/http2-spec/#extensibility
>
>   allows extending flags for existing frame types,
>   but I do not see that explicitly forbidden either. )
>
> [*] If Websocket hanshake and new stream is opened with new frame type,
>     that is not possible before both endpoints are received SETTINGS
>     frame wich imply WS_OVER_HTTP/2.
>
>
> This was not to me (but as "cc:"), but seems that I commented anyway ☺
>
> > Thanks,
>
> / Kari Hurtta
>
>

---

From: Yutaka Hirano <[email-masked]>
Date: Thu, 17 Jul 2014 15:24:30 +0900

> indication.  At that point, game on.

Thank you, you are right.

The server knows the HTTP/2 connection is capable of WS OVER HTTP/2 when it
receives a SETTINGS frame with WS_CAPABLE.
The client knows the HTTP/2 connection is capable of WS OVER HTTP/2 when
the handshake succeeds.

Then we need only client => server SETTINGS frame with WS_CPABABLE.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 17 Jul 2014 09:29:01 -0700

> Then we need only client => server SETTINGS frame with WS_CPABABLE.

Other way around:

The client knows the server is WS capable when it receives a
WS_CAPABLE setting from the server.
The server knows the client is WS capable when it receives a WS request.

The only problem there is the added delay.  A client can't open a
websocket in the first flight.

---

From: Yutaka Hirano <[email-masked]>
Date: Fri, 18 Jul 2014 02:06:19 +0900

> websocket in the first flight.

So I plan to allow the client to start an opening handshake without knowing
that the HTTP/2 connection is capable of WS.
If it is not capable of WS, the client may retry connecting with the native
WS.
To do so, the server must know the capability when the handshake request
arrives.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 17 Jul 2014 10:08:02 -0700

> If it is not capable of WS, the client may retry connecting with the native

You can do that; the failure mode is no worse, but you can succeed faster.

> To do so, the server must know the capability when the handshake request

The capability of the client is apparent when a request for :scheme =
"ws[s]" arrives.

---

From: Yutaka Hirano <[email-masked]>
Date: Fri, 18 Jul 2014 02:32:01 +0900

> The capability of the client is apparent when a request for :scheme =

The capability of the client is apparent, but the server should know if all
intermediaries support WS over HTTP/2.
An intermediary can transfer :scheme = ws[s] request without understanding
WS over HTTP/2.
Am I missing something?

---

From: Martin Thomson <[email-masked]>
Date: Thu, 17 Jul 2014 13:16:16 -0700

On 17 July 2014 13:06, Kari Hurtta <[email-masked]> wrote:
> seems allow :scheme = ws[s]

This is true, though you aren't really getting what you think at that
point.  See RFC 7230:

   HTTP is also designed for use as an intermediation protocol for
   translating communication to and from non-HTTP information systems.
   HTTP proxies and gateways can provide access to alternative
   information services by translating their diverse protocols into a
   hypertext format that can be viewed and manipulated by clients in the
   same way as HTTP services.

The implication here being that the data from the non-HTTP information
system can be put in an HTTP message.

> So I guess that intermediaries does not need care about
> :scheme. Is there anything why web server needs care
> about :scheme request field ?  Looks like that web
> server may "safely" ignore it.

That entirely depends on what the intermediary is doing.  A tunnel can
probably ignore the field.

> In both cases intermediaries need to know that its is full-duplex
> communications inside of HTTP/2 stream (that is not HTTP
> request/reply exchange).

Correct.

> In other hand :method = CONNECT does not like

You can use CONNECT to do websockets, but that's not the form of the
protocol we've been discussing.  We've been discussing integration, as
opposed to tunneling.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Thu, 17 Jul 2014 16:35:37 +0000

In message <CABkgnnWey=[email-masked]>

>websocket in the first flight.

So since this seems to be the standard reply to pretty much everything
else, why doesn't it just negotiate WS with TLS (or Update:) to begin
with ?

Why the detour over HTTP/2 ?

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 17 Jul 2014 14:56:40 -0700

> Why the detour over HTTP/2 ?

Multiplexing.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 23 Jul 2014 11:59:13 -0700

On 23 July 2014 11:56, Kari Hurtta <[email-masked]> wrote:
> If :scheme is not "http" or "https", is there necessary ":path" -component?

Yes.  It may be empty, as you say.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 24 Jul 2014 06:15:11 -0700

I'll fix the description of :path.

On 24 July 2014 03:34, Kari Hurtta <[email-masked]> wrote:
> OPTIONS http://some.host HTTP/1.1
>
> seems translate to
>
>  :method    = OPTIONS
>  :scheme    = http
>  :authority = some.host
>  :path      = *

That's a fun one, isn't it?  I'll see what I can do there.  The number
of "except when..." clauses in this protocol continues to surprise
(and depress) me.

---

From: Amos Jeffries <[email-masked]>
Date: Fri, 25 Jul 2014 01:52:32 +1200

On 25/07/2014 1:15 a.m., Martin Thomson wrote:
> On 24 July 2014 03:34, Kari Hurtta wrote:

That seems to be an invalid mapping in Karis' example.

The input 1.1 URI has a path-empty pattern (0<pchar>), but the h2 being
generated shows a path-rootless segment pattern.

The recipient of that 1.1 request is supposed to assume path value of
"/" in these cases not "*".

So IMHO there is nothing new that need be said. The 1.1->2 gateway maps
:path to either empty value or to "/" same as any 1.1 intermediary would.

Amos

---

From: Martin Thomson <[email-masked]>
Date: Thu, 24 Jul 2014 07:09:43 -0700

> "/" in these cases not "*".

The link Kari provided shows that there is an exception for OPTIONS
requests in the absolute form that address an HTTP URI with path-empty
form.

https://svn.tools.ietf.org/svn/wg/httpbis/specs/rfc7230.html#rfc.section.5.3.4

That seems pretty explicit to me.  Maybe you can look at the editor's
draft and see if my latest tweaks have corrected this.

---

From: Amos Jeffries <[email-masked]>
Date: Fri, 25 Jul 2014 03:14:17 +1200

On 25/07/2014 2:09 a.m., Martin Thomson wrote:
> On 24 July 2014 06:52, Amos Jeffries wrote:

Oh, right. I missed that. (I'm not getting Kari's mails for some reason,
just your replies).

> draft and see if my latest tweaks have corrected this.

I forsee a problem with the current editors draft text for proxies
relaying this in the h2->1.1 direction since the following is a valid
URL request:

 OPTIONS http://some.host* HTTP/1.1

IMHO it be more correct to say simply that :path may be omitted on
OPTIONS and represents a request for "*" asterisk-form? as opposed to a
0-length :path field which represents the path-empty case.

CONNECT requests provides precedent for omission.

Amos

---

From: Martin Thomson <[email-masked]>
Date: Thu, 24 Jul 2014 08:27:36 -0700

> 0-length :path field which represents the path-empty case.

That would permit a more correct reconstruction of the original 1.1 request.

I think that I need a second opinion before making such a change. What
do others think?

---

From: Martin Thomson <[email-masked]>
Date: Thu, 24 Jul 2014 08:43:02 -0700

On 24 July 2014 08:33, Kari Hurtta <[email-masked]> wrote:
> I'm not sure that this is easy to parse.

Yeah, I've tried again.  Please let me know if you think I could make it better.

>    - This field MUST NOT be empty for http or https URIs;
>    - http or https URIs that do not contain a path component
>      MUST include a value of '/' or '*'
>
>    - If :method is not OPTIONS and http or https URI do
>      not contain a path, then :path is '/'
>    - If this is OPTIONS request in asterisk form, then
>      :path is '*'
>    - If :method is OPTIONS and http or https URI do
>      not contain a path, then :path is '*'
>
> I got that enumerated ?

Yep.  Makes me wish that my suggestion to eliminate the asterisk form
a few years back was accepted by the working group.

---

From: Michael Sweet <[email-masked]>
Date: Thu, 24 Jul 2014 11:49:19 -0400

I think for OPTIONS the client can omit all but the :method pseudo header.  In any case, I'm +1 on clarifying this in the spec, particularly for "OPTIONS *".

> I think that I need a second opinion before making such a change. What

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: Julian Reschke <[email-masked]>
Date: Thu, 24 Jul 2014 19:18:42 +0200

> I think that I need a second opinion before making such a change. What

I believe this is right, but it seems to me we really need a set of 
examples to make sure we got everything right.

We also should consider an erratum for 1.1 that discourages use of the 
asterisk form for any new functionality.

Best regards, Julian

---

From: Martin Thomson <[email-masked]>
Date: Thu, 24 Jul 2014 10:26:21 -0700

On 24 July 2014 10:18, Julian Reschke <[email-masked]> 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

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.

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 24 Jul 2014 13:26:14 -0400

Er, :authority?

--
Mark Nottingham   http://www.mnot.net/

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 24 Jul 2014 13:26:01 -0400

We already say “The asterisk-form of request-target is only used for a server-wide OPTIONS request”. <http://httpwg.github.io/specs/rfc7230.html#rfc.section.5.3.4>

On 24 Jul 2014, at 1:18 pm, Julian Reschke <[email-masked]> 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.
> 
> We also should consider an erratum for 1.1 that discourages use of the asterisk form for any new functionality.
> 
> Best regards, Julian
>

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 24 Jul 2014 10:36:02 -0700

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

No, it is

  OPTIONS http://example.com:80 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

---

From: Julian Reschke <[email-masked]>
Date: Thu, 24 Jul 2014 19:43:29 +0200

> We already say “The asterisk-form of request-target is only used for a server-wide OPTIONS request”. <http://httpwg.github.io/specs/rfc7230.html#rfc.section.5.3.4>

True, but not fully sufficient, as long as people disagree with what 
"server-wide" means... I've seen attempts to use "OPTIONS *" both when 
revising WebDAV and when introducing PATCH, and it took a lot of energy 
to prevent it.

Do we have an example for use of "OPTIONS *" that actually makes sense?

Best regards, Julian

---

From: Martin Thomson <[email-masked]>
Date: Thu, 24 Jul 2014 10:50:00 -0700

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

Thanks.  I don't think we have a problem here then.

---

From: Amos Jeffries <[email-masked]>
Date: Fri, 25 Jul 2014 11:48:50 +1200

> Er, :authority?

Is routinely omitted in HTTP/1.0 port 80 requests without Host: header.
Recipient is required to assume itself.

Amos

> 
> On 24 Jul 2014, at 11:49 am, Michael Sweet wrote:
> 
>> On Jul 24, 2014, at 11:27 AM, Martin Thomson wrote:
>>
>>> On 24 July 2014 08:14, Amos Jeffries  wrote:

---

From: Michael Sweet <[email-masked]>
Date: Fri, 25 Jul 2014 00:59:39 -0400

HTTP Upgrade

Sent from my iPad

> On Jul 24, 2014, at 1:43 PM, Julian Reschke <[email-masked]> wrote:
> 
> True, but not fully sufficient, as long as people disagree with what "server-wide" means... I've seen attempts to use "OPTIONS *" both when revising WebDAV and when introducing PATCH, and it took a lot of energy to prevent it.
>

---

From: Michael Sweet <[email-masked]>
Date: Fri, 25 Jul 2014 08:37:11 -0400

I would expect the host information to be passed in the Host: header, e.g.:

    OPTIONS * HTTP/1.1             HEADERS
    Host: www.example.com   ==>      + END_STREAM
                                     + END_HEADERS
                                       :method = OPTIONS
                                       host = www.example.com

---

From: Julian Reschke <[email-masked]>
Date: Fri, 25 Jul 2014 15:19:55 +0200

> HTTP Upgrade

And it couldn't have been "OPTIONS /"?

There's nothing else in HTTP/1.1 that requires as many exceptions and 
special cases as the asterisk form... Cost/benefit etc.

Best regards, Julian

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Fri, 25 Jul 2014 17:22:47 +0000

>special cases as the asterisk form... Cost/benefit etc.

Drop OPTIONS from HTTP/2, it's not worth the trouble.

---

From: Julian Reschke <[email-masked]>
Date: Fri, 25 Jul 2014 19:25:59 +0200

> Drop OPTIONS from HTTP/2, it's not worth the trouble.

That would break CORS and some uses of WebDAV.

OPTIONS is not the problem, "*" is.

Best regards, Julian

---

From: "Roy T. Fielding" <[email-masked]>
Date: Fri, 25 Jul 2014 12:24:09 -0700

> OPTIONS is not the problem, "*" is.

Neither one is a problem (and HEAD has far more special cases than *).
Cruft is crufty, usually by necessity.

....Roy

---

From: Greg Wilkins <[email-masked]>
Date: Sat, 26 Jul 2014 08:39:31 +1000

> OPTIONS is not the problem, "*" is.

Neither are problems for me.  But taking them out would be a problem as
then I would suddenly have more h1 only behaviour.  Code above the
transport layer has already been dealt with the handle '*', so unless we
are changing the whole stack, changing this kind of semantics at the
transport layer is just a pain.

For a general policy for dropping things, I think that if it can't be
dropped from a h1 server today, then it can't be dropped from h2 without
causing more special cases and complexity.

cheers

-- 
Greg Wilkins <[email-masked]>
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.

---

From: Michael Sweet <[email-masked]>
Date: Mon, 28 Jul 2014 09:15:27 -0400

Julian,

I don't know, but RFC 2817 is pretty explicit about how to do a mandatory upgrade that applies to the connection and not to a particular resource:

   3.2 Mandatory Upgrade

   If an unsecured response would be unacceptable, a client MUST send an
   OPTIONS request first to complete the switch to TLS/1.0 (if
   possible).

       OPTIONS * HTTP/1.1
       Host: example.bank.com
       Upgrade: TLS/1.0
       Connection: Upgrade

I think that's the crux - "*" has a different semantic than "/", and in HTTP/1.x you can't pass an empty path on the request line.

On Jul 25, 2014, at 9:19 AM, Julian Reschke <[email-masked]> wrote:

> There's nothing else in HTTP/1.1 that requires as many exceptions and special cases as the asterisk form... Cost/benefit etc.
> 
> Best regards, Julian
>

---

From: Amos Jeffries <[email-masked]>
Date: Tue, 29 Jul 2014 03:15:45 +1200

Amos

---

From: Michael Sweet <[email-masked]>
Date: Mon, 28 Jul 2014 11:49:32 -0400

Amos,

"http://some.host" does not have an empty path, it has the default path of "/".

Also, you aren't always doing TLS upgrade with the origin server, you are doing it with whomever you are connected, e.g., a proxy.

---

From: Amos Jeffries <[email-masked]>
Date: Tue, 29 Jul 2014 23:04:32 +1200

> Also, you aren't always doing TLS upgrade with the origin server, you are doing it with whomever you are connected, e.g., a proxy.

Under RFC2616 you would be half right. 2616 contains the blanket text
"
If the abs_path is not present in the URL, it MUST be given as "/" when
used as a Request-URI for a resource (section 5.1.2).
"

Which seems to outright prohibit use of empty path in URI.

However, today ...

RFC 7230 section 2.7.1 defines the (new) relevant piece of URI ABNF as
"authority path-abempty"

RFC 3986 defines path-abempty as 'begins with "/" or is empty'.

  Ergo, "http://some.host" contains an empty path.

RFC 7230 section 2.7.3 states regarding this empty path:
"
When not being used in absolute form as the request target of an OPTIONS
request, an empty path component is equivalent to an absolute path of
"/", so the normal form is to provide a path of "/" instead.
"

... "http://some.host" being absolute form, and the request under
discussion here being OPTIONS.

Amos

> 
> 
> On Jul 28, 2014, at 11:15 AM, Amos Jeffries wrote:
>

---

From: Michael Sweet <[email-masked]>
Date: Tue, 29 Jul 2014 08:40:07 -0400

Amos,

On Jul 29, 2014, at 7:04 AM, Amos Jeffries <[email-masked]> wrote:
> ...

Right, for a proxied OPTIONS request, the special casing in RFC 7230 section 5.3.4 covers mapping "OPTIONS http://some.host" to "OPTIONS *".  But you don't proxy OPTIONS requests with "Connection: upgrade".

But my original point was that "OPTIONS *" is used to upgrade the connection to the endpoint, with "*" meaning "the server as a whole". You may not like "*", but more than 10^9 existing clients have software that uses it for secure printing, and its use has been a proposed standard for a long time.