fix: send Vary: Accept on content-negotiated responses

[krokicki]

Problem

In production, the initial browser load of the index page often shows the ListBuckets XML instead of the HTML index; reloading then shows the HTML. Not reproducible in local deployments.

Root cause

The index (/) and bucket browse (/{bucket}/) URLs serve either HTML or XML for the same URL, negotiated purely on the Accept header, but the responses never set Vary: Accept. The production nginx proxy_cache keys only on scheme/host/method/URI, so whichever variant is requested first after cache expiry is cached and served to everyone for 15 minutes. S3 clients (aws cli, neuroglancer, monitors) frequently hit / for ListBuckets without text/html in their Accept header, poisoning the cache with XML for browsers. A hard reload sends Cache-Control: no-cache, which the nginx config maps to proxy_cache_bypass, refreshing the entry with HTML — hence "reload fixes it".

Local deployments have no shared cache in front, so the bug never appears there.

Fix

Set Vary: Accept on both variants at the two negotiated fork points in target_dispatcher. nginx's proxy cache honors upstream Vary by default (since 1.7.7), so HTML and XML variants are now cached separately with no nginx changes required.

Testing

Added test_vary_accept_header covering both paths × both Accept types. Full suite: 71 passed.

@StephanPreibisch @allison-truhlar

[krokicki]

Thanks a lot for pointing out this problem, @allison-truhlar! It should be fixed in prod now.