cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tamar Furman (tfurman)" <tfur...@cisco.com>
Subject RE: REST response over https - no-cache always set
Date Sun, 20 Feb 2011 11:54:04 GMT
Hi Sergey - 

The response.reset did the trick. I reset the context response then built the ws.rs response
using the response builder like before. The cache control header is gone.
Thank you very much.

Any explanation why this cleanup is needed and why the ResponseBuilders is using the context
response headers? We have other request-response compiling some download files, running just
HttpServletResponse and these seams to work fie with the IE8 no-cache limitation just fine
by setting it to false.

In any case... The reset solved it for the REST response as well.
Tamar

-----Original Message-----
From: Sergey Beryozkin [mailto:sberyozkin@gmail.com] 
Sent: Monday, February 14, 2011 3:22 PM
To: users@cxf.apache.org
Subject: Re: REST response over https - no-cache always set

I run the jaxrs https test locally, without explicitly setting Cache-Control no such header
is returned and if I call
setNoCache(false):

CacheControl control = new CacheControl(); control.setNoCache(false); return Response.ok().cacheControl(control).entity(doGetBook(id)).build();

then the client code shows that no 'no-cache' value is present in the Cache-Control header.

But the test is using the emdedded Jetty. Thus it seems like the servlet container that you
use forces this value.

I'm looking at

http://stackoverflow.com/questions/3788766/forcing-no-cache-for-internet-explorer-over-https-with-http-response-headers


I guess what you can try to do is to have

@Context
HttpServletResponse response;

injected and then do response.reset() before continuing using Response, just  to verify it
works.
If it does then you may consider  coding against the injected HttpServletResponse only. I'd
also consider not injecting HttpServletResponse and instead creating a custom Servlet filter
which would only do

response.reset()

before delegating further.

Let me know if it helps
Sergey


On Mon, Feb 14, 2011 at 12:46 PM, Sergey Beryozkin <sberyozkin@gmail.com> wrote:
> Hi
>
> Sorry for a delay...
>
> On Mon, Feb 14, 2011 at 8:10 AM, Tamar Furman (tfurman) 
> <tfurman@cisco.com> wrote:
>> Hi -
>>
>> I'm straggling this problem for several days and will appreciate any 
>> help.
>>
>> I'm using CXF 2.2.6 providing REST services over https. I have the 
>> following problem with download function via rest. The method returns 
>> ws.rs.Response and encapsulates in the content a download file. All 
>> works nice with Firefox but fails on IE8. There is a known bug on IE8 
>> that requires that such https response avoid 'no-cache' header. 
>> However no matter how I build the response header it seams that the 
>> ResponseBuilder puts in the 'no-cache' one and I can't get rid of it.
>>
>> Here is a snip of my code:
>>
>>                        CacheControl cc = new CacheControl();
>>                        cc.setNoStore(true);
>>                        cc.setNoCache(false);
>>                        Response res = Response.ok(file).
>>                                         type("application/octet").
>>                                         cacheControl(cc).
>>                                         header("Content-Disposition",

>> "attachment; filename=" + fileName).
>>
>> header("Content-Length:",Long.toString(file.length())).
>>                                         build();
>>
>>
>>
>> also tried:
>>                         header("Cache-Control", "no-store").
>>                         header("Cache-Control", "private, max-age=1").
>>                         header("Pragma", "no-store").
>>
>>
>>
>> No matter what, I always see the following headers return to the client:
>>
>>        Pragma  No-cache
>>        Cache-Control   no-cache, no-store;no-transform
>>
>> Any idea how can I solve this with this cxf ResponseBuilder?
>>
>
> What happens if you do not use the CacheControl utility at all ?
>
> I'm wondering, is it the underlying HTTPS implementation that forces 
> the 'no-cache' value ?
>
> Cheers, Sergey
>
>> Thanks,
>> T.
>>
>

Mime
View raw message