- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Thu, 12 Jun 2014 10:51:32 -0700
- 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