#32055 closed Bug (wontfix)
Add Surrogate-Control header to the 304 response
Reported by: | bungoume | Owned by: | nobody |
---|---|---|---|
Component: | HTTP handling | Version: | dev |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Unreviewed | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
The Surrogate-Control header is used in CDN cache control.
Currently, the Surrogate-Control header is removed on NotModified response, and only like the Cache-Control headers are returned.
Therefore, applications with a Surrogate-Control based caching strategy may cause unexpected caching to take place in the CDN.
Change History (5)
comment:1 by , 4 years ago
Resolution: | → needsinfo |
---|---|
Status: | new → closed |
comment:2 by , 4 years ago
Taking the intent of rfc7232 section 4.1, it seems to me that we should reduce the amount of data by excluding all but the headers related to the cache.
Surrogate-Control is a cache control header that has been around for a long time and is increasingly used in CDNs.
Its notations are the same as Cache-Control.
I think the reason it's not mentioned in rfc7232 is because it's only recently started to be used.
This is used in cases where you want to keep browser cache control and CDN cache control separate.
If Surrogate-Control disappears with 304, the CDN or proxy will use Cache-Control as a cache control, and it won't do what you expect it to do.
To get around this, well need to re-implement ConditionalGetMiddleware on our own.
I believe it is more beneficial in many use cases to leave the headers in place rather than erasing them based on rfc7232.
https://www.w3.org/TR/edge-arch/
https://docs.fastly.com/en/guides/configuring-caching#surrogate-control
comment:3 by , 4 years ago
Thanks for the extra detail. I can see that this has been defined for nearly 20 years, so it isn't something new, but it is quite niche.
The point here is that it allows you to configure the caching behaviour of a proxy independently from the caching behaviour of the browser. (See here.)
The main question is whether you are only using max-age
with Surrogate-Control
?
If that is the case, then you can use s-maxage
with Cache-Control
to achieve the same goal. (Fastly, MDN)
The only difference is that this is not stripped, but private
caches (a.k.a. the browser) will still ignore it.
I found this useful guide. It seems to imply that there are very few options other than max-age
that are likely to be of interest or work.
On that basis I'm -½ on doing anything here if you only care about max-age
for Cache-Control
as there is an good alternate in s-maxage
for Cache-Control
.
That said, if there is a strong need for doing something more complex that would require the Surrogate-Control
header, there is no easy extension point for adding this in a custom middleware due to how this is currently implemented. In that case I could see a good reason to add this with a suitable comment.
comment:4 by , 4 years ago
Has patch: | unset |
---|---|
Resolution: | needsinfo → wontfix |
Wontfixed based on Nick's comment.
comment:5 by , 4 years ago
...there is no easy extension point for adding this in a custom middleware due to how this is currently implemented.
It might make sense to review a proposal to add such an extension point. (Ideally you don't want to have to re-implement the whole middleware to add an extra header...)
Surrogate-Control
is not mentioned in Section 4.1 of RFC 7232 (see #19705). Can you provide more details, any spec etc.? I'm not an expert, but I've never heard about this HTTP header, it seems that is not really common.