HttpURLConnection.setUseCaches
|
|||||||||||||
![]()
HttpURLConnection.setUseCaches
|
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 |
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 |
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 |
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 > > |
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 >> >> |
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
|
Free forum by Nabble | Edit this page |