RE: preconnect link relation and ALTSVC frame

ALTSVC dosen’t say “move on,” it provides information about better options.  The client can legitimately continue to make requests on that connection and keep the Alt-Svc info for next time, or it can try to act on it now.  I don't know whether any browsers do this, but one logical implementation would be:

  *   Client begins opening the connection to the Alternative
  *   When a request needs to be made, it uses whichever already-established connection is most preferred



Amos is right that the point of Preconnect is to save the connection establishment time from blocking the download of resources; that would suggest that the client wouldn’t ever block waiting for an alternative to become available, but might reasonably race the connection establishment with the generation of the request.



-----Original Message-----
From: Lucas Pardue [mailto:Lucas.Pardue@bbc.co.uk]
Sent: Wednesday, November 8, 2017 9:32 AM
To: Amos Jeffries <squid3@treenet.co.nz>; ietf-http-wg@w3.org
Subject: 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.

-----------------------------