[ 
https://issues.apache.org/jira/browse/WICKET-5372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13781812#comment-13781812
 ] 

Brandon Fuller commented on WICKET-5372:
----------------------------------------

In your comment, you said this is a "not documented" behavior of IE.  I found 
you the documentation:

http://support.microsoft.com/kb/323308

The fixes range but in IE8, it requires the user to set a registry setting in 
order to download files under SSL using Wicket.  Its odd that server-side Java 
framework would have the policy of requiring users to change registry settings 
to fully utilize the framework.  Seems much simpler to change the framework 
back so that its compatible with the browsers.  It worked fine in Wicket 1.4.  
Its a regression.

> 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)

Reply via email to