Re: [quicwg/base-drafts] Semantics of SETTINGS_MAX_HEADER_LIST_SIZE (#2516)

[Mike Bishop <[e-mail]>]

In theory, this should advertise the limit beyond which a peer wouldn't have propagated the payload anyway; it permits, but doesn't require, the entity that's about to send the payload to send a (miniscule) error in the opposite direction / on the API rather than forwarding a message it expects to be rejected based on header size.  That's purely an optimization, and it's always acceptable to just transfer the big thing and find out at the end that it failed.

Because there could be multiple intermediaries, it's entirely possible that one stream could see an EXCESSIVE_LOAD error even though the headers weren't too large for the first hop upstream.  That's one of the biggest reasons this needs to be a stream error -- the setting is hop-by-hop, but enforcement is ultimately on a per-request basis across the set of hops.

If used this way, it shouldn't break anything that wasn't broken before -- things that would have failed will simply fail faster.  If you don't implement it, then you'll still eventually get an EXCESSIVE_LOAD or a 400.

I agree that the current text doesn't reflect this usage pattern.  If we agree that this is the correct way to envision it, I'll write up better text.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2516#issuecomment-486456057