HttpURLConnection.setUseCaches(false) adds Cache-Control/Pragm-a: no-cache to Client requests

[Martynas Jusevičius]

Hey all,

when debugging why HTTP proxy cache is not caching requests, I noticed
mysterious Cache-Control: no-cache and Pragma: no-cache headers on
them.

First I suspected my Jersey Client (v1.18) code, but it was setting no
such headers.

Then I googled and started suspecting Tomcat, which has configuration
for exact same thing (see disableProxyCaching and
securePagesWithPragma attributes):
https://tomcat.apache.org/tomcat-7.0-doc/config/valve.html

When I configured Tomcat but the headers did not go away, I started to
suspect Jersey. I debugged URLConnectionClientHandler which uses
HttpURLConnection. When checking JavaDoc I came across the
setUseCaches() method:
https://docs.oracle.com/javase/7/docs/api/java/net/URLConnection.html#setUseCaches(boolean)

It does not explicitly mention Cache-Control or Pragma, but I wrote a
simple Java test which confirmed setUseCaches(false) is the reason why
Cache-Control: no-cache and Pragma: no-cache are added to
HttpURLConnection requests (at least GET).

The connection used by the Client exhibits this behavior as both
uc.getUseCaches() and uc.getDefaultUseCaches() return false at this
point:
https://github.com/jersey/jersey-1.x/blob/master/jersey-client/src/main/java/com/sun/jersey/client/urlconnection/URLConnectionClientHandler.java#L163

Now the question: can I configure Jersey Client or the JVM to use
caches, i.e. to invoke setUseCaches(true) instead? Or otherwise remove
the headers from the client request?

I don't know what the justification was for this "feature", but I
think it is totally unacceptable that a component in a webapp stack
silently adds headers to requests, and even fails to clearly document
that.


Martynas
graphityhq.com

[Martynas Jusevičius]

ApacheHttpClient does not seem to have this problem, so I will be
switching to it.

On Mon, Apr 25, 2016 at 10:34 PM, Martynas Jusevičius
<[hidden email]> wrote:

> Hey all,
>
> when debugging why HTTP proxy cache is not caching requests, I noticed
> mysterious Cache-Control: no-cache and Pragma: no-cache headers on
> them.
>
> First I suspected my Jersey Client (v1.18) code, but it was setting no
> such headers.
>
> Then I googled and started suspecting Tomcat, which has configuration
> for exact same thing (see disableProxyCaching and
> securePagesWithPragma attributes):
> https://tomcat.apache.org/tomcat-7.0-doc/config/valve.html
>
> When I configured Tomcat but the headers did not go away, I started to
> suspect Jersey. I debugged URLConnectionClientHandler which uses
> HttpURLConnection. When checking JavaDoc I came across the
> setUseCaches() method:
> https://docs.oracle.com/javase/7/docs/api/java/net/URLConnection.html#setUseCaches(boolean)
>
> It does not explicitly mention Cache-Control or Pragma, but I wrote a
> simple Java test which confirmed setUseCaches(false) is the reason why
> Cache-Control: no-cache and Pragma: no-cache are added to
> HttpURLConnection requests (at least GET).
>
> The connection used by the Client exhibits this behavior as both
> uc.getUseCaches() and uc.getDefaultUseCaches() return false at this
> point:
> https://github.com/jersey/jersey-1.x/blob/master/jersey-client/src/main/java/com/sun/jersey/client/urlconnection/URLConnectionClientHandler.java#L163
>
> Now the question: can I configure Jersey Client or the JVM to use
> caches, i.e. to invoke setUseCaches(true) instead? Or otherwise remove
> the headers from the client request?
>
> I don't know what the justification was for this "feature", but I
> think it is totally unacceptable that a component in a webapp stack
> silently adds headers to requests, and even fails to clearly document
> that.
>
>
> Martynas
> graphityhq.com

[Gili]

This makes it even more likely that this is a bug in Jersey (it should
behave the same regardless of the underlying implementation). Can you
please file a bug report?

Gili

On 2016-04-26 4:36 AM, Martynas Jusevičius wrote:

> ApacheHttpClient does not seem to have this problem, so I will be
> switching to it.
>
> On Mon, Apr 25, 2016 at 10:34 PM, Martynas Jusevičius
> <[hidden email]> wrote:
>> Hey all,
>>
>> when debugging why HTTP proxy cache is not caching requests, I noticed
>> mysterious Cache-Control: no-cache and Pragma: no-cache headers on
>> them.
>>
>> First I suspected my Jersey Client (v1.18) code, but it was setting no
>> such headers.
>>
>> Then I googled and started suspecting Tomcat, which has configuration
>> for exact same thing (see disableProxyCaching and
>> securePagesWithPragma attributes):
>> https://tomcat.apache.org/tomcat-7.0-doc/config/valve.html
>>
>> When I configured Tomcat but the headers did not go away, I started to
>> suspect Jersey. I debugged URLConnectionClientHandler which uses
>> HttpURLConnection. When checking JavaDoc I came across the
>> setUseCaches() method:
>> https://docs.oracle.com/javase/7/docs/api/java/net/URLConnection.html#setUseCaches(boolean)
>>
>> It does not explicitly mention Cache-Control or Pragma, but I wrote a
>> simple Java test which confirmed setUseCaches(false) is the reason why
>> Cache-Control: no-cache and Pragma: no-cache are added to
>> HttpURLConnection requests (at least GET).
>>
>> The connection used by the Client exhibits this behavior as both
>> uc.getUseCaches() and uc.getDefaultUseCaches() return false at this
>> point:
>> https://github.com/jersey/jersey-1.x/blob/master/jersey-client/src/main/java/com/sun/jersey/client/urlconnection/URLConnectionClientHandler.java#L163
>>
>> Now the question: can I configure Jersey Client or the JVM to use
>> caches, i.e. to invoke setUseCaches(true) instead? Or otherwise remove
>> the headers from the client request?
>>
>> I don't know what the justification was for this "feature", but I
>> think it is totally unacceptable that a component in a webapp stack
>> silently adds headers to requests, and even fails to clearly document
>> that.
>>
>>
>> Martynas
>> graphityhq.com

[Martynas Jusevičius]

https://java.net/jira/browse/JERSEY-3103

On Tue, Apr 26, 2016 at 3:24 PM, cowwoc <[hidden email]> wrote:

> This makes it even more likely that this is a bug in Jersey (it should
> behave the same regardless of the underlying implementation). Can you please
> file a bug report?
>
> Gili
>
>
> On 2016-04-26 4:36 AM, Martynas Jusevičius wrote:
>>
>> ApacheHttpClient does not seem to have this problem, so I will be
>> switching to it.
>>
>> On Mon, Apr 25, 2016 at 10:34 PM, Martynas Jusevičius
>> <[hidden email]> wrote:
>>>
>>> Hey all,
>>>
>>> when debugging why HTTP proxy cache is not caching requests, I noticed
>>> mysterious Cache-Control: no-cache and Pragma: no-cache headers on
>>> them.
>>>
>>> First I suspected my Jersey Client (v1.18) code, but it was setting no
>>> such headers.
>>>
>>> Then I googled and started suspecting Tomcat, which has configuration
>>> for exact same thing (see disableProxyCaching and
>>> securePagesWithPragma attributes):
>>> https://tomcat.apache.org/tomcat-7.0-doc/config/valve.html
>>>
>>> When I configured Tomcat but the headers did not go away, I started to
>>> suspect Jersey. I debugged URLConnectionClientHandler which uses
>>> HttpURLConnection. When checking JavaDoc I came across the
>>> setUseCaches() method:
>>>
>>> https://docs.oracle.com/javase/7/docs/api/java/net/URLConnection.html#setUseCaches(boolean)
>>>
>>> It does not explicitly mention Cache-Control or Pragma, but I wrote a
>>> simple Java test which confirmed setUseCaches(false) is the reason why
>>> Cache-Control: no-cache and Pragma: no-cache are added to
>>> HttpURLConnection requests (at least GET).
>>>
>>> The connection used by the Client exhibits this behavior as both
>>> uc.getUseCaches() and uc.getDefaultUseCaches() return false at this
>>> point:
>>>
>>> https://github.com/jersey/jersey-1.x/blob/master/jersey-client/src/main/java/com/sun/jersey/client/urlconnection/URLConnectionClientHandler.java#L163
>>>
>>> Now the question: can I configure Jersey Client or the JVM to use
>>> caches, i.e. to invoke setUseCaches(true) instead? Or otherwise remove
>>> the headers from the client request?
>>>
>>> I don't know what the justification was for this "feature", but I
>>> think it is totally unacceptable that a component in a webapp stack
>>> silently adds headers to requests, and even fails to clearly document
>>> that.
>>>
>>>
>>> Martynas
>>> graphityhq.com
>
>

[Martynas Jusevičius]

The bug was closed as Won't Fix for 1.x:
https://java.net/jira/browse/JERSEY-3103

I'm pretty sure it is present in 2.x as well, but I don't think Adam
bothered to check.

On Tue, Apr 26, 2016 at 3:53 PM, Martynas Jusevičius
<[hidden email]> wrote:

> https://java.net/jira/browse/JERSEY-3103
>
> On Tue, Apr 26, 2016 at 3:24 PM, cowwoc <[hidden email]> wrote:
>> This makes it even more likely that this is a bug in Jersey (it should
>> behave the same regardless of the underlying implementation). Can you please
>> file a bug report?
>>
>> Gili
>>
>>
>> On 2016-04-26 4:36 AM, Martynas Jusevičius wrote:
>>>
>>> ApacheHttpClient does not seem to have this problem, so I will be
>>> switching to it.
>>>
>>> On Mon, Apr 25, 2016 at 10:34 PM, Martynas Jusevičius
>>> <[hidden email]> wrote:
>>>>
>>>> Hey all,
>>>>
>>>> when debugging why HTTP proxy cache is not caching requests, I noticed
>>>> mysterious Cache-Control: no-cache and Pragma: no-cache headers on
>>>> them.
>>>>
>>>> First I suspected my Jersey Client (v1.18) code, but it was setting no
>>>> such headers.
>>>>
>>>> Then I googled and started suspecting Tomcat, which has configuration
>>>> for exact same thing (see disableProxyCaching and
>>>> securePagesWithPragma attributes):
>>>> https://tomcat.apache.org/tomcat-7.0-doc/config/valve.html
>>>>
>>>> When I configured Tomcat but the headers did not go away, I started to
>>>> suspect Jersey. I debugged URLConnectionClientHandler which uses
>>>> HttpURLConnection. When checking JavaDoc I came across the
>>>> setUseCaches() method:
>>>>
>>>> https://docs.oracle.com/javase/7/docs/api/java/net/URLConnection.html#setUseCaches(boolean)
>>>>
>>>> It does not explicitly mention Cache-Control or Pragma, but I wrote a
>>>> simple Java test which confirmed setUseCaches(false) is the reason why
>>>> Cache-Control: no-cache and Pragma: no-cache are added to
>>>> HttpURLConnection requests (at least GET).
>>>>
>>>> The connection used by the Client exhibits this behavior as both
>>>> uc.getUseCaches() and uc.getDefaultUseCaches() return false at this
>>>> point:
>>>>
>>>> https://github.com/jersey/jersey-1.x/blob/master/jersey-client/src/main/java/com/sun/jersey/client/urlconnection/URLConnectionClientHandler.java#L163
>>>>
>>>> Now the question: can I configure Jersey Client or the JVM to use
>>>> caches, i.e. to invoke setUseCaches(true) instead? Or otherwise remove
>>>> the headers from the client request?
>>>>
>>>> I don't know what the justification was for this "feature", but I
>>>> think it is totally unacceptable that a component in a webapp stack
>>>> silently adds headers to requests, and even fails to clearly document
>>>> that.
>>>>
>>>>
>>>> Martynas
>>>> graphityhq.com
>>
>>

[Marek Potociar]

Hi Martynas,

I wonder what makes you so sure about the issue being present in Jersey 2.x? Did you test it? Do you have a reproducer?

FWIW, I have checked all our code and I cannot find ANY reference to use of the setUseCaches(…) method on that you are referring to. So, we’re not changing anything and just keeping the default behavior in this case. 

If you or any other user is not happy with the default configuration on the HttpURLConnection used by default Jersey client connector provider, you can simply configure your own ConnectionFactory and create the HttpURLConnection configured the way you like.

Does that solve your problem?

Marek

On 18 May 2016, at 11:07, Martynas Jusevičius <[hidden email]> wrote:

The bug was closed as Won't Fix for 1.x:
https://java.net/jira/browse/JERSEY-3103

I'm pretty sure it is present in 2.x as well, but I don't think Adam
bothered to check.

On Tue, Apr 26, 2016 at 3:53 PM, Martynas Jusevičius
<[hidden email]> wrote:

https://java.net/jira/browse/JERSEY-3103

On Tue, Apr 26, 2016 at 3:24 PM, cowwoc <[hidden email]> wrote:

This makes it even more likely that this is a bug in Jersey (it should
behave the same regardless of the underlying implementation). Can you please
file a bug report?

Gili


On 2016-04-26 4:36 AM, Martynas Jusevičius wrote:

ApacheHttpClient does not seem to have this problem, so I will be
switching to it.

On Mon, Apr 25, 2016 at 10:34 PM, Martynas Jusevičius
<[hidden email]> wrote:

Hey all,

when debugging why HTTP proxy cache is not caching requests, I noticed
mysterious Cache-Control: no-cache and Pragma: no-cache headers on
them.

First I suspected my Jersey Client (v1.18) code, but it was setting no
such headers.

Then I googled and started suspecting Tomcat, which has configuration
for exact same thing (see disableProxyCaching and
securePagesWithPragma attributes):
https://tomcat.apache.org/tomcat-7.0-doc/config/valve.html

When I configured Tomcat but the headers did not go away, I started to
suspect Jersey. I debugged URLConnectionClientHandler which uses
HttpURLConnection. When checking JavaDoc I came across the
setUseCaches() method:

https://docs.oracle.com/javase/7/docs/api/java/net/URLConnection.html#setUseCaches(boolean)

It does not explicitly mention Cache-Control or Pragma, but I wrote a
simple Java test which confirmed setUseCaches(false) is the reason why
Cache-Control: no-cache and Pragma: no-cache are added to
HttpURLConnection requests (at least GET).

The connection used by the Client exhibits this behavior as both
uc.getUseCaches() and uc.getDefaultUseCaches() return false at this
point:

https://github.com/jersey/jersey-1.x/blob/master/jersey-client/src/main/java/com/sun/jersey/client/urlconnection/URLConnectionClientHandler.java#L163

Now the question: can I configure Jersey Client or the JVM to use
caches, i.e. to invoke setUseCaches(true) instead? Or otherwise remove
the headers from the client request?

I don't know what the justification was for this "feature", but I
think it is totally unacceptable that a component in a webapp stack
silently adds headers to requests, and even fails to clearly document
that.


Martynas
graphityhq.com