Re: preconnect link relation and ALTSVC frame

[Amos Jeffries <[e-mail]>]

On 09/11/17 04:32, Lucas Pardue wrote:
> Hello,
> 
> Reading around the Web Linking [1] topic a bit, I came up with the 
> following scenario involving preconnect [2]. My general question is, 
> could a client act on Alt-Svc information during its preconnect action 
> (and if so, do any implementations do this). I wondered if anyone had 
> been on this thought journey and had an opinion.
> 
>  1. Client makes a request for https://example.org/foo
>  2. Server responds with foo resource and Link header:
>      1. Link: <https://bar.example.org>; rel=preconnect
>  3. Client attempts to initiate a preconnect and performs full
>     connection handshake.
>      1. During TLS handshake, ALPN selects H2
>  4. Connection is established and server sends an ALTSVC frame
>     containing an Alt-Svc-Field-Value of:
>      1. hq=":50781”, h2=”baz.example.org”
>  5. Client attempts to establish connection to one of the alternatives?
> 

Firstly, why would a client do (5) immediately after (3) ? The whole 
point of preconnect is to avoid the latency / RTTs doing (5) would 
incur. Normally I would expect a client needing multiple connections to 
preconnect all of them ASAP - ie at (3) to avoid the latency, not 
waiting until after (4).

Secondly, if another connection were necessary sometime after (4) there 
is effectively no difference for the client between connecting to 
bar.example.com:443, bar.example.com:50781 and baz.example.org when 
fetching URLs for "http://bar.example.org". That is required or they 
would not be valid as alternatives for each other.

AYJ