[
https://issues.apache.org/jira/browse/WICKET-5372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13782679#comment-13782679
]
Martin Grigorov commented on WICKET-5372:
-----------------------------------------
So, the "defaults" are actually set by JRResource, not by the framework.
The only "solution" that I see is to add logic in
org.apache.wicket.protocol.http.servlet.ServletWebResponse#setHeader and
#addHeader methods to check webRequest.getContainerRequest().getScheme() if the
header value is "Cache-Control" and to remove "no-store" from it.
This will slow down the processing for all applications and will fix the
behavior for 0.01% of them.
You can use custom ServletWebResponse and override these two methods if you
think it is better than setting cache duration only for the resource. But I
think this change should not be made in the framework because of its
performance impact.
If you have better solution please share it.
If you don't agree with me then please start a discussion at
[email protected] mailing list. Maybe someone else will find a solution
that works for everyone.
> Cache Disable Headers Break IE8 Under HTTPS
> -------------------------------------------
>
> Key: WICKET-5372
> URL: https://issues.apache.org/jira/browse/WICKET-5372
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 6.9.0
> Reporter: Brandon Fuller
> Priority: Minor
>
> I am serving up a non-cached PDF resource from Wicket with:
> getRequestCycle().scheduleRequestHandlerAfterCurrent(new
> ResourceRequestHandler(pdfResource, null));
> All is fine for most users. However, our IE8 users cannot perform the
> download. The get a dialog saying that the resource cannot be downloaded. I
> did some testing and found that it works fine over HTTP but not HTTPS.
> I found this stack overflow article that explains:
> http://stackoverflow.com/questions/1038707/cant-display-pdf-from-https-in-ie-8-on-64-bit-vista
> I see in WebResponse that Wicket is setting the Cache-Control and Pragma
> values incorrectly as far as IE8 is concerned. This explains the behavior.
> To prove, I changed the resource in wicket to have a cache duration of one
> second and the resource downloads over SSL just fine. Not the worst
> workaround but I was hoping this could be addressed.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
