Re: HTTP/2, "h2t" and protocol identifiers in general

On 26 February 2014 17:14, Mark Nottingham <mnot@mnot.net> wrote:
> HTTPS URI = always h2t
> HTTP URI as we know it = h2
> HTTP URI w/ TLS = h2t

That was the point that confused me.  I thought that you were
proposing only the last, without the first change.  Sounds good,
though I would reverse the labels (as originally suggested).

This however, I can't really get behind Roberto's associated implications:

On 26 February 2014 20:13, Roberto Peon <grmocg@gmail.com> wrote:
> What I'd like to see is the following.
> h2 means that we're using the HTTP/2 protocol, and it implies at minimum
> that the server supports accepting whatever is the default protocol for the
> port, typically HTTPS if using ALPN.
> The scheme defines the application-layer semantics of any particular stream.
>
> That h2 implied acceptance of HTTPS on :443 or HTTP on :80 would not
> preclude using another scheme.

This relies heavily on things being implicit, and side effects.

If I want to offer "h2" (or "h2t") on a non-standard port, I would
really like to avoid the implication that I also provide service on
443 or 80 as a result.  Such an implication has consequences that I'd
like to avoid.

I don't really see what this buys.  We've discussed permitting the
service of http: resources that omit the port number over TLS on port
443.  That's already stretching my tolerance for behaviour based on
implicit signals.  But I've been convinced that it's useful.  I'm also
happy that it is sufficient.

(I'm ok with the part about having the scheme defining what semantics
are expected of the protocol.  That's what they already do, basically.
 Contradicting that would be a big mistake.)

Received on Thursday, 27 February 2014 18:11:46 UTC