Accessing 'system' header fields implicitly added by HttpClient

Daniel Fuchs daniel.fuchs at oracle.com
Fri May 21 08:47:59 UTC 2021


Hi Moataz,

This sounds like a reasonable request, with a concrete use case.

I have logged https://bugs.openjdk.java.net/browse/JDK-8267510

best regards,

-- daniel

On 20/05/2021 15:58, Moataz Abdelnasser wrote:
> Hi!
> 
> 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.
> 
> Regards,
> Moataz
> 



More information about the net-dev mailing list