Sorry if this is a bit off-topic, but I tried to debug this on my own and I also searched Google for quite some time but couldn't find anything yet. I'm now hoping that someone on the list can maybe help with this.
I have a Hunchentoot (pre-1.0.0) application running on a customer's server which has been online and running fine for a couple of years now. (It has seen a few updates, but none in the recent months.) The application sits behind an Apache which acts as a proxy in the usual way. Content is served to the client through https which is done by Apache, i.e. Apache talks plain http to Hunchentoot.
The application serves, amongst other things, RTF and PDF documents to the clients which are dynamically generated. Some time ago, in the first half of this year, this ceased to work for RTF documents when the client was MSIE 7. This happened after my customer's MSIE 7 browsers received an automatic software update from Microsoft. A bit later the browsers were updated again (to MSIE 8) and now PDF download is also broken. With Firefox, all is still fine. Also, if I access the website through http instead of https, downloads (RTF and PDF) still work fine.
Judging from the timing, this is pretty obviously an incompatibility between my app (and/or Hunchentoot) which was introduced due to the MSIE upgrade, but after fighting with this for quite some time I still don't have a clue what the reason is and how I could fix it. The log files don't reveal anything, they just show a normal download of the RTF/PDF document - while MSIE claims that it didn't receive anything.
Any ideas/hints?
Thanks, Edi.
Is it possibly an issue with the client security settings? IE is very fussy about websites (and potentially other entities) which have HTTPS and HTTP components. This seems less likely to be a problem with PDFs, but it may be possible, especially if it's HTTPS PDF embedded in HTTP-served pages or vice versa. Alternatively, is there anything wrong with your certificate? It's possible the IE is rejecting it out of hand, though it generally at least asks.
This issue has become worse in IE8. Previously, default behaviour on the mixed content thing was to pop up a box asking if the user wanted to load everything; the default was 'Yes', causing everything to be loaded. In IE8, it's the other way round; 'Yes' will cause it NOT to load non-secure objects. This is going to break all sorts of things, of course :)
If you view the page in Firefox or Safari do you get a warning image in the status bar? Rob
2009/6/15 Edi Weitz edi@agharta.de:
Sorry if this is a bit off-topic, but I tried to debug this on my own and I also searched Google for quite some time but couldn't find anything yet. I'm now hoping that someone on the list can maybe help with this.
I have a Hunchentoot (pre-1.0.0) application running on a customer's server which has been online and running fine for a couple of years now. (It has seen a few updates, but none in the recent months.) The application sits behind an Apache which acts as a proxy in the usual way. Content is served to the client through https which is done by Apache, i.e. Apache talks plain http to Hunchentoot.
The application serves, amongst other things, RTF and PDF documents to the clients which are dynamically generated. Some time ago, in the first half of this year, this ceased to work for RTF documents when the client was MSIE 7. This happened after my customer's MSIE 7 browsers received an automatic software update from Microsoft. A bit later the browsers were updated again (to MSIE 8) and now PDF download is also broken. With Firefox, all is still fine. Also, if I access the website through http instead of https, downloads (RTF and PDF) still work fine.
Judging from the timing, this is pretty obviously an incompatibility between my app (and/or Hunchentoot) which was introduced due to the MSIE upgrade, but after fighting with this for quite some time I still don't have a clue what the reason is and how I could fix it. The log files don't reveal anything, they just show a normal download of the RTF/PDF document - while MSIE claims that it didn't receive anything.
Any ideas/hints?
Thanks, Edi.
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
Just on this, even the favicon being HTTP and the document being HTTPS is sometimes enough to trigger this behaviour, and if IE is set to 'High' security I don't think it'll even ask; it just won't load things. Rob
2009/6/15 Robert Synnott rsynnott@gmail.com:
Is it possibly an issue with the client security settings? IE is very fussy about websites (and potentially other entities) which have HTTPS and HTTP components. This seems less likely to be a problem with PDFs, but it may be possible, especially if it's HTTPS PDF embedded in HTTP-served pages or vice versa. Alternatively, is there anything wrong with your certificate? It's possible the IE is rejecting it out of hand, though it generally at least asks.
This issue has become worse in IE8. Previously, default behaviour on the mixed content thing was to pop up a box asking if the user wanted to load everything; the default was 'Yes', causing everything to be loaded. In IE8, it's the other way round; 'Yes' will cause it NOT to load non-secure objects. This is going to break all sorts of things, of course :)
If you view the page in Firefox or Safari do you get a warning image in the status bar? Rob
2009/6/15 Edi Weitz edi@agharta.de:
Sorry if this is a bit off-topic, but I tried to debug this on my own and I also searched Google for quite some time but couldn't find anything yet. I'm now hoping that someone on the list can maybe help with this.
I have a Hunchentoot (pre-1.0.0) application running on a customer's server which has been online and running fine for a couple of years now. (It has seen a few updates, but none in the recent months.) The application sits behind an Apache which acts as a proxy in the usual way. Content is served to the client through https which is done by Apache, i.e. Apache talks plain http to Hunchentoot.
The application serves, amongst other things, RTF and PDF documents to the clients which are dynamically generated. Some time ago, in the first half of this year, this ceased to work for RTF documents when the client was MSIE 7. This happened after my customer's MSIE 7 browsers received an automatic software update from Microsoft. A bit later the browsers were updated again (to MSIE 8) and now PDF download is also broken. With Firefox, all is still fine. Also, if I access the website through http instead of https, downloads (RTF and PDF) still work fine.
Judging from the timing, this is pretty obviously an incompatibility between my app (and/or Hunchentoot) which was introduced due to the MSIE upgrade, but after fighting with this for quite some time I still don't have a clue what the reason is and how I could fix it. The log files don't reveal anything, they just show a normal download of the RTF/PDF document - while MSIE claims that it didn't receive anything.
Any ideas/hints?
Thanks, Edi.
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
-- Robert Synnott http://myblog.rsynnott.com MSN: rsynnott@gmail.com Jabber: rsynnott@gmail.com
Hello,
,---- | The application serves, amongst other things, RTF and PDF documents to | the clients which are dynamically generated. Some time ago, in the | first half of this year, this ceased to work for RTF documents when | the client was MSIE 7. This happened after my customer's MSIE 7 | browsers received an automatic software update from Microsoft. `----
This sounds like problem I had some time ago. It happened for https with no-cache headers sent with generated content - some IE versions refused to save it to a temp file and passed an empty file to acroread.
-- pm
On Tue, Jun 16, 2009 at 6:20 AM, Peter Mikulapeter.mikula@gmail.com wrote:
This sounds like problem I had some time ago. It happened for https with no-cache headers sent with generated content - some IE versions refused to save it to a temp file and passed an empty file to acroread.
Thanks to all who replied! Peter, this was the solution - I sent no-cache headers and this is what newer IE versions in SSL didn't accept. Removing these headers solved the problem.
Thanks again, Edi.
Edi Weitz edi@agharta.de writes:
On Tue, Jun 16, 2009 at 6:20 AM, Peter Mikulapeter.mikula@gmail.com wrote:
This sounds like problem I had some time ago. It happened for https with no-cache headers sent with generated content - some IE versions refused to save it to a temp file and passed an empty file to acroread.
Thanks to all who replied! Peter, this was the solution - I sent no-cache headers and this is what newer IE versions in SSL didn't accept. Removing these headers solved the problem.
Thanks again, Edi.
Since this reminds me of problems I once had (and which I "solved" by saving a PDF file and serving it with HANDLE-STATIC-FILE):
How can one make sure that no "no-cache" header is sent? (I'm quite sure I did not directly require "no-cache" when sending the PDF data.)
Thanks, Nicolas
On Fri, Jun 19, 2009 at 2:22 PM, Nicolas Neussneuss@math.uni-karlsruhe.de wrote:
Since this reminds me of problems I once had (and which I "solved" by saving a PDF file and serving it with HANDLE-STATIC-FILE):
How can one make sure that no "no-cache" header is sent?
By not sending it... :)
Seriously, if you don't send it explicitly (e.g. by calling the NO-CACHE convenience function), Hunchentoot won't send it behind your back.
Edi.
-
Edi Weitz -
Nicolas Neuss -
Peter Mikula -
Robert Synnott