[Django] #32055: Add Surrogate-Control header to the 304 response
Django
-----------------------------------------+------------------------
Reporter: bungoume | Owner: nobody
Type: Bug | Status: new
Component: HTTP handling | Version: master
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 1
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-----------------------------------------+------------------------
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/32055>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Reporter: bungoume | Owner: nobody
Type: Bug | Status: closed
Component: HTTP handling | Version: master
Keywords: | Triage Stage: Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by felixxm):
* status: new => closed
* resolution: => needsinfo
Comment:
`Surrogate-Control` is not mentioned in
[https://tools.ietf.org/html/rfc7232#section-4.1 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.
--
Ticket URL: <https://code.djangoproject.com/ticket/32055#comment:1>
Django
Reporter: bungoume | Owner: nobody
Type: Bug | Status: closed
Component: HTTP handling | Version: master
Keywords: | Triage Stage: Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by bungoume):
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, we''ll 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
--
Ticket URL: <https://code.djangoproject.com/ticket/32055#comment:2>
Django
Reporter: bungoume | Owner: nobody
Type: Bug | Status: closed
Component: HTTP handling | Version: master
Keywords: | Triage Stage: Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Nick Pope):
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
[https://docs.fastly.com/en/guides/configuring-caching#applying-different-
cache-rules-for-fastly-and-browsers 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. ([https://docs.fastly.com/en/guides/configuring-
caching#cache-control-s-maxage Fastly], [https://developer.mozilla.org/en-
US/docs/Web/HTTP/Headers/Cache-Control#Expiration 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 [https://www.integralist.co.uk/posts/http-caching/
guide]. It seems to imply that there are
[https://www.integralist.co.uk/posts/http-caching/#surrogate-control-
directives 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.
--
Ticket URL: <https://code.djangoproject.com/ticket/32055#comment:3>
Django
Reporter: bungoume | Owner: nobody
Type: Bug | Status: closed
Component: HTTP handling | Version: master
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by felixxm):
* has_patch: 1 => 0
* resolution: needsinfo => wontfix
Comment:
Wontfixed based on Nick's comment.
--
Ticket URL: <https://code.djangoproject.com/ticket/32055#comment:4>
Django
Reporter: bungoume | Owner: nobody
Type: Bug | Status: closed
Component: HTTP handling | Version: master
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Carlton Gibson):
> ...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...)
--
Ticket URL: <https://code.djangoproject.com/ticket/32055#comment:5>