Thanks Devon!
So just to clarify our request flow is:
Client > CDN > Go Reverse Proxy > Origin
Our Go Reverse Proxy has historically been responsible for adding caching
headers (e.g. Cache-Control and Surrogate-Control) when the origins have
failed to do so (as a way to ensure things are cached appropriately).
It's unclear to me why you should be setting an etag header if you're a
> proxy.
>
That's why when it came to looking at setting serve stale defaults for our
origins (e.g. stale-while-revalidate and stale-if-error) I realized that
somewhere along the chain an appropriate ETag/Last-Modified should be set
and that's why I started wondering if our proxy should be responsible for
setting them.
Even then I felt like setting Last-Modified was way outside the
responsibility of our proxy, but that maybe setting of ETag would have
sufficed.
Unless you're serving from the filesystem handler (which does
> implement IMS/INM), you'll need to implement these yourself.
>
I think your other related answers might explain to me why the go reverse
proxy doesn't support conditional requests, in that it's NOT a 'caching
proxy' and so being able to handle that revalidation logic wouldn't make
sense.
> Note that you _could_ simply proxy this to the origin and let it
> handle the validation. This is often overkill for what people actually
> need, but it is guaranteed to work.
>
OK, so as we are indeed just proxying the request pretty much 'as is' to
the origin, i.e. the CDN is making the revalidation conditional request
when our stale-while-revalidate TTL expires, I'm guessing (I appreciate
this is the 'basics' of how a proxy works, but I want to talk it through in
case I'm mistaken in any way!) the go proxy will transparently keep that
information for the origin to respond with the appropriate
ETag/Last-Modified, and the go proxy again will transparently pass back
their response through to the CDN to then update its cache if it indeed got
a `200 OK` from origin or to continue serving stale if the origin returned
a `304 Not Modified` (and in either case I expect the origin should send
ETag/Last-Modified headers regardless of 200/304 status').
A hash function over the body of the response would constitute strong
> validation. I'm not sure why you'd need to mix in the path; there's
> nothing wrong with serving the exact same content between two
> endpoints, and the ETag is tied to a response object.
>
Ah ok, so I was thinking along these lines, but was getting confused
between content that is cached vs content that is rendered at 'runtime'
(e.g. I was getting confused with the response containing a
