:question: [Question]: Configurable and/or default `Vary` for content negotiation

[fmigneault]

Questions

The Vary: Origin (or omitting it) is now used based on the configured CORS.

Another use would be Vary: Accept, (and maybe also Accept-Encoding and Accept-Language), to ensure caching (if applicable) is considered for different response content representations on the same HTTP method / URL.

Should these be set by default across the server?

Should it be a separate variable, which would then be combined with the other Vary: Origin auto-computed?

References

• https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Vary
• Issues with STAC CORS options #610
• add BIRDHOUSE_PROXY_CORS_ALLOW_ORIGIN setting #611

[mishaschwartz]

I think this makes sense only if its the proxy that is changing the content based on these header values.

If it's the upstream service (i.e. stac, thredds, etc.) that modifies the content these then those services should be the ones updating the Vary header.

So I think that the best thing to do is not use proxy_hide_header Vary (if we are anywhere) and let the upstream service pass it's own response headers through the reverse proxy to the user.

[tlvu]

Another use would be Vary: Accept, (and maybe also Accept-Encoding and Accept-Language), to ensure caching (if applicable) is considered for different response content representations on the same HTTP method / URL.

Just trying to understand the use-case, we want these additional Vary header to enable caching of the previous pages or just the previous headers?

For dynamic pages, would this caching create potential problems?

Could you maybe describe the scenario with an example showing with and without the additional header, what are the differences? Which would showcase the benefits of the header?

Before going into implementation (default across the server, separate variable), I just want to understand the use-case.

[fmigneault]

@mishaschwartz

If it's the upstream service (i.e. stac, thredds, etc.) that modifies the content these then those services should be the ones updating the Vary header.

Very good point.
I am not sure though if nginx would simply override it now that we set it explicitly, or whether 2 headers will propagate/append... to test.
It seems logical to let the service indicate when/where content-based Vary headers apply, but the Origin cannot be set by them, since they are not aware of this configuration.

One of the reason I could have seen Vary: Accept, ... be set on nginx side is that API/service-specific proxy_cache definitions, including proxy_cache_key "$scheme$request_method$host$request_uri$http_accept"; could be set adequately to reflect the corresponding caching that applies to certain locations, although it could also be set generally this way whether Vary: Accept applies or not.

@tlvu
The idea of Vary is to provide a hint to browsers/clients that caching (if any is applied) should consider these headers as well since the structure of the response will change (even if they were omitted in the request). This hints them to create separate cache keys not solely based on HTTP [method] [url], but by including the values of these extra headers as well.

If any caching does happen, which could be nice for certain big JSON API responses to reduce reprocessing the operation, it decreases the chance of mismatching content-types/cache-keys happening. In other words, the client cannot assume that GET https://example.com/api (without Accept) will always answer the same thing.

[tlvu]

The idea of Vary is to provide a hint to browsers/clients that caching (if any is applied) should consider these headers as well since the structure of the response will change (even if they were omitted in the request). This hints them to create separate cache keys not solely based on HTTP [method] [url], but by including the values of these extra headers as well.

Ah ok, it's clearer for me know. Vary header do not control whether page caching is enabled or not. It's to tell that additional header need to be considered when performing cache validatation. Ex: even if the URL did not change, but if the header specified by Vary changes, the cache should be reloaded.

In this case, how can we have a default across server since each app can potentially have a different behavior/need? Or the default should be very conservative and add all the possible headers that could potentially influence a page? Can such default list of headers even be found or agreed upon?

Is there a mechanism to add add Vary on demand for some specific app only, but not on the entire server as default value?

[fmigneault]

Yes, the default should be fairly conservative. IMO, Vary: Accept, Origin (if using CORS) or Vary: Accept (otherwise), would be reasonable since that is often the default intention for most API interactions. When Accept is irrelevant/omitted, there shouldn't be that many cache variations since clients would typically omit them anyway, or use the browser HTML+XML default. In other situations where Accept does matter, each cache would have to be done on its own anyway, or the API responds with an error if unacceptable, where cache shouldn't happen.

If an API needs another more specific header combination, it should override it in its own location block, using the combination:

location /.../ {
  proxy_pass http://.../;
  proxy_hide_header Vary;
  add_header Vary "<custom>" always;
}

The main reason why a server-wide variable would be required is to deal with the CORS/no-CORS situation, but other optimizations could consider ETag and provide 304 Not Modified responses as applicable to reduce transferred content size.