Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#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 Mariusz Felisiak, 4 years ago

Resolution: needsinfo
Status: newclosed

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.

comment:2 by bungoume, 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 Nick Pope, 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 Mariusz Felisiak, 4 years ago

Has patch: unset
Resolution: needsinfowontfix

Wontfixed based on Nick's comment.

comment:5 by Carlton Gibson, 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...)

Note: See TracTickets for help on using tickets.
Back to Top