the http workshop 2024 is over

[Nils Goroll]

... so here is my report addition from the train, after having had to leave a 
little early.

Most of the general reporting work has already been done by the workshop's 
inofficial correspondent Daniel Stenberg, so I will link to his blog and just 
add some comments from my personal notes. I will mostly only comment where I 
believe to have anything to add, so not all the points are reflected. Read 
Daniel's blog and the slides...

DAY1
----

https://daniel.haxx.se/blog/2024/11/13/the-2024-http-workshop/

Make Cleartext HTTP harder

https://github.com/HTTPWorkshop/workshop2024/blob/main/talks/1.%20Security/cleartext.pdf

I was probably one of those "bringing back the discussion" which Daniel thought 
had been left behind, but I find the idea of a "central url registry" simply 
evil and with the increasing lock-in of user-agents, this topic felt to me like 
dialing up the frog-boiler's temperature another tick.

The valid argument behind the discussion is the need to solve the tls downgrade 
issue. HSTS only works after having visited a site at least once, so there is 
the "preload list" and sure enough, that doesn't scale. I do not have a solution 
to the problem either, but killing clear text http deployments does really not 
seem like the right choice to me - even if they are already made less and less 
attractive because of reduced support for newer browser features.

HTTP 2/3 abuses

https://github.com/HTTPWorkshop/workshop2024/blob/main/talks/1.%20Security/glitches.pdf

Read the slides! We as Varnish-Cache should really consider Willy's explicit and 
implicit advise from his experience and I expect to personally get back to this 
relatively soon, because I am getting closer to the H2 re-implementation which I 
have on my list for next year...

QUIC pacing

https://github.com/HTTPWorkshop/workshop2024/blob/main/talks/2.%20Performance/quic%20pacing.pdf

Maybe not for our immediate attention, but the insights seem very valuable. In 
particular the "send acks in intervals of rtt" advice, and I learned an 
interesting detail from side discussions: At least two people from different 
teams said that they found SO_TXTIME to be broken on Linux.

Priorities

https://github.com/HTTPWorkshop/workshop2024/blob/main/talks/2.%20Performance/HTTP%20prioritization.pdf

One interesting idea from the discussion: implement one priority as a cache 
pre-warm "fetch, but don't send at all". If the client then decides it actually 
wants the object, it updates the priority...

DSR

https://github.com/HTTPWorkshop/workshop2024/blob/main/talks/2.%20Performance/QUIC%20cache%20DSR.pdf

Discussing the topic after the workshop, I learned about one use case which was 
absolutely not clear to me: At scale, the traffic patterns can be such that it 
does not pay off to copy longtail objects to another "neighbor" cache in the 
same cluster. So yes, DSR seems to make sense. Though the particular design 
presented looked to me like there really should be an easier way...

DAY2
----

https://daniel.haxx.se/blog/2024/11/13/the-2024-workshop-day-two/

CAPSULE

This made me realize again really _how_ many not even particularly new things 
there are where we as Varnish-Cache have nothing to offer...

Reverse HTTP

https://github.com/HTTPWorkshop/workshop2024/blob/main/talks/3.%20Semantics/reverse%20HTTP.pdf

This sounds interesting from our perspective, I think. Others already have 
non-standardized solutions and workarounds, but the use case really seems 
compelling: Instead of connecting to backends, have backends connect to us. An 
interesting question is how to signal the need for more capacity, for which the 
answer probably is a streams usage in h2/3, but I am not sure if an easy 
solution exists for h1.

MoQ

https://github.com/HTTPWorkshop/workshop2024/blob/main/talks/4.%20Evolution/MoQ.pdf

My engineer mind got hooked, even though this topic probably has close to zero 
relevance for what I am doing at the moment. Overall impression: The MoQ folks 
could probably benefit from learning about some common caching topics...

Multiplexing in the year 2024

https://github.com/HTTPWorkshop/workshop2024/blob/main/talks/4.%20Evolution/multiplexing.pdf

A smart choice of title to maybe not trigger some defensive reflexes, but it was 
really about H3 over QUIC-ish over TLS over TCP. I can see how that could be 
useful besides maybe reducing the maintenance burden: For clients on 
udp-unfriendly networks and for traffic in environments with excellent, 
predictable network infrastructure, where all the quic (re)prioritization tricks 
are not relevant.

DAY3
----

https://daniel.haxx.se/blog/2024/11/14/workshop-season-six-episode-three/

Do you speak http

https://github.com/HTTPWorkshop/workshop2024/blob/main/talks/5.%20Testing/testing.pdf

Vtest had multiple appearances here and I pushed my neglected vtest-related 
tasks further up my list of bad consciousness.

I had to leave during the following break to not risk to miss the one eurostar 
train I really had to take to make it home in time for a birthday...

Nils



-- 

Nils Goroll (he/him)

** * * UPLEX - Nils Goroll Systemoptimierung

Scheffelstraße 32
22301 Hamburg

tel +49 40 28805731
mob +49 170 2723133
fax +49 40 42949753

xmpp://slink@jabber.int.uplex.de/

http://uplex.de/