Repository navigation
Make 'immutable' cache-control value HTTP/3 QPACK compatible #149
Description
At the moment passing an immutable: true option adds an immutable value to the Cache-Control header. Ideally the header would be put as a separate Cache-Control header entry making such request QPACK-compatible.
Note: When evaluating the use of immutable and QPACK: If you're concerned that immutable changes the predefined value provided by QPACK, consider that in this case, the immutable part can be encoded separately by splitting the Cache-Control value into two lines — though this is dependent on the encoding algorithm a particular QPACK implementation uses.
(MDN reference)
Activity
dougwilson commentedon Sep 23, 2022
I like it 👍 . Not sure if there are any implications to cache software in handing multiple header or not, but I don't think it would matter since cache-control is optimistic anyway if an intermediary just looked at the first cache-control header only.
bilashcse commentedon Aug 12, 2026
The
immutableoption is handled bysend, which builds the wholeCache-Controlvalue there, so the change has to land in that module. I opened pillarjs/send#315 for it.With that patch,
immutable: trueresults in two field-lines instead of one combined value, which leavespublic, max-age=<seconds>matchable against the QPACK static table. RepeatedCache-Controlfield-lines are combined by caches, so the effective directives are unchanged. It ships with tests that assert the exactrawHeadersthat go on the wire and a README note; lint plus Node.js 18-25 on ubuntu and windows all pass.Once it is released,
serve-staticpicks it up through itssenddependency with no code change needed here.