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

Re: #492: Alt-Svc header host restriction

From: Martin Thomson <martin.thomson@gmail.com>
Date: Thu, 12 Jun 2014 10:51:32 -0700
Message-ID: <CABkgnnX7A0REukLDFvjmK59S9TnGJARxJsxmU-_cOc3to8knsg@mail.gmail.com>
To: Julian Reschke <julian.reschke@gmx.de>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
On 12 June 2014 10:25, Julian Reschke <julian.reschke@gmx.de> wrote:
>> p.s., I think we agreed to lift the restriction on other host names
>> and move that to -encryption.
>
> a) the restriction is gone, no? b) -encryption?

=b.  I think that the key here is that:

The key is that the server that you end up on needs to be determined
to be authoritative by the means described in the definition of the
URL you are resolving.

Thus, for http: URIs, the server you end up on needs to use DNS name
resolution and IP routing based on the host name that is in the URI.

For https: URIs, the server you end up on needs to present a
certificate that is valid for the host name that is in the URI.

This is a property of HTTP/1.1 that we don't want to change:
https://tools.ietf.org/html/rfc7230#section-9.1

>> p.p.s., Do we want q= on these?
>
> Or define an ordering.
>
> Speaking of which - is it ok that the frame only can carry on
> alternate-service?

I didn't really consider that.  It's worth thinking through.
Subsequent frames could be said to replace ones that appear
previously.  Or we could define a more robust format that allows for
multiple entries.  Or we could allow all values to last until their
max-age; and then have values that match on all values other than
max-age update the max-age.  Let me raise some issues for this.
Received on Thursday, 12 June 2014 17:52:00 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:31 UTC