#32055: Add Surrogate-Control header to the 304 response
-------------------------------+--------------------------------------
Reporter: bungoume | Owner: nobody
Type: Bug | Status: closed
Component: HTTP handling | Version: master
Severity: Normal | Resolution: needsinfo
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 <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/066.1d3d7b7d76cbe3b3383b0a3703407c41%40djangoproject.com.
