W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2019

Re: HTTP Alternative Services Best Practices?

From: Daniel Stenberg <daniel@haxx.se>
Date: Tue, 17 Dec 2019 20:48:28 +0100 (CET)
To: Lucas Pardue <lucaspardue.24.7@gmail.com>
cc: QUIC WG <quic@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <alpine.DEB.2.20.1912172040300.23555@tvnag.unkk.fr>
On Mon, 16 Dec 2019, Lucas Pardue wrote:

> invokes default values for parameters, "ma" is fresh for 24 hours and 
> "persist" is false (i.e. clear alternative cache on network changes). One 
> could imagine how this could cause bursts of activity at regular periods, or 
> cascades due to end-user local conditions such as flocking or hopping.

The "persist" thing gives me, as author of the alt-svc handling in curl, a 
small headache too. Let me elaborate:

curl is a command line tool that you typically fire off one or two requests 
with now and then again at a later point.

When curl saves/caches the alt-svc information because we want to take 
advantage of for example HTTP/3 at subsequent invokes, we just have no idea if 
the network changed or not in between the invokes. Figuring out if a network 
chanfes is hard enough when you catch it in run-time (I wrote a lot of such 
code for Firefox), but even worse when you do occasional runs with potentially 
long intervals.

I'm struggling to come up with a decent way to deal with this. Right now I 
just ignore the persistent parameter completely, but I realize that's just 
waiting for a case when it will hurt me. I'm leaning towards either always 
consider the network as changed, or to add some very rudimentary checks that 
for example consider it the same if the source IP is still the same or 

(the curl alt-svc implementation is still marked "experimental" and as such 
isn't actually used very widely yet)


  / daniel.haxx.se
Received on Tuesday, 17 December 2019 19:48:40 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:15:43 UTC