RE: preconnect link relation and ALTSVC frame

Hi Amos,

I'm not sure I follow your response.

>
> 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).

The sequence is serial. This isn't another Link header, this is the target of a preconnect telling the connection initiator to move on via an ALTSVC frame. An example use case for this would be to warm up a QUIC connection. There is no QUIC URL that can be used with preconnect to tell a client to go directly there.

In step 4, https://bar.example.org  presents new information to the client, that alternatives to are available. Step 5 was intended to ask whether the connection to alternative is chained to the preconnection activity (in other words, only complete once alternatives are tested and chosen, or ignored).

> 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.

Right, so in a subsequent request, a client effective request URI for https://bar.example.org/bar would be issued to one of the pre-warmed alternatives. For example, to the HTTP/QUIC endpoint running on bar.example.org:50781.

Kind regards
Lucas


-----------------------------
http://www.bbc.co.uk

This e-mail (and any attachments) is confidential and
may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in
error, please delete it from your system.
Do not use, copy or disclose the
information in any way nor act in reliance on it and notify the sender
immediately.
Please note that the BBC monitors e-mails
sent or received.
Further communication will signify your consent to
this.
-----------------------------

Received on Wednesday, 8 November 2017 17:32:28 UTC