`cdn-max-age-case-insensitive` encourages acceptance of nonstandard structured field syntax
Closed this issue · 2 comments
In RFC 8941, we have:
Member keys cannot contain uppercase characters.
The cdn-max-age-case-insensitive test uses CDN-Cache-Control: MaX-aGe=3600, which shouldn't parse per the structured field spec.
Should this be a check instead of an optimal test?
Oh, good point!
Probably for now, yes.
We're having a discussion in the retrofit/sf-bis specs about loosening requirements for some headers that opt into it. Considering that cdn-* is sort of a retrofit header, it might be worth updating it to use that. Just thinking out loud, not sure yet...
Probably for now, yes.
Sounds good, I'll follow up with a small PR to change it over.
We're having a discussion in the retrofit/sf-bis specs about loosening requirements for some headers that opt into it. Considering that cdn-* is sort of a retrofit header, it might be worth updating it to use that.
Ah, I suppose it's time I finally subscribe to the mailing list 🙂
For what it's worth, the approach I'm taking so far with RFC 9213 implementation is to explicitly decide on a per-headername basis whether to use structured fields or legacy syntax. Given Fastly's historical use of the nonstandard Surrogate-Control, therefore, we might end up with:
[(CDN-Cache-Control, structured), (Surrogate-Control, legacy), (Cache-Control, legacy)]
Since we're not going to be producing these headers too often, it's no sweat for us to be pickier about how the new headers are parsed. But I could imagine that causing a bit of extra work for an origin that wants to, say, rename a Surrogate-Control field produced by legacy code to CDN-Cache-Control and expect full compatibility.