Accessing 'system' header fields implicitly added by HttpClient
daniel.fuchs at oracle.com
Fri May 21 08:47:59 UTC 2021
This sounds like a reasonable request, with a concrete use case.
I have logged https://bugs.openjdk.java.net/browse/JDK-8267510
On 20/05/2021 15:58, Moataz Abdelnasser wrote:
> I've recently released an HTTP cache
> (https://mizosoft.github.io/methanol/caching) that operates as part of
> an interceptor chain built atop a standard HttpClient.
> Currently, the cache can store only one response per request. However,
> request headers can specify multiple response variants if nominated by
> the 'Vary' header
> (e.g. gzip & deflate variants if varying on Accept-Encoding). To
> ensure a response is selected only if it is the corrected variant,
> incoming requests' Vary-nominated fields
> must match against those in the initiating request.
> The bummer is that HttpClient can augment requests with implicit
> header fields (e.g. Cookie, Authorization, etc.), and accessing these
> seems to be impossible (tested that
> with 'response.request().headers()', please correct me if I'm wrong).
> The cache has to render a response uncacheable if it decides it varies
> on these fields, as their values cannot be
> known in the initiating request, so they can't be matched against when
> new requests are made. It'd be nice if one could access these headers,
> maybe via 'response.request().headers()',
> or something like 'response.networkRequest().headers()'. This would
> increase cache's efficiency. Additionally, I can find it useful for
> debugging as it's always good to know what
> modifications the client makes to requests.
More information about the net-dev