Bug #541
Pdf problem with Internet Explorer documentation/default config
| Status: | Fixed | Start: | ||
| Priority: | Normal | Due date: | ||
| Assigned to: | - | % Done: | 0% |
|
| Category: | documentation | |||
| Target version: | - | |||
| Pending: | Resolution: | duplicate |
||
Description
With the default lighttpd config IE crashes when it tries to open a pdf file. This setting in the config fixes it:
$HTTPurl =~ "\.pdf$" {
server.range-requests = "disable"
}
I came across this by accident on a Danish site and guessed what it meant. But other than that the solution is nowhere to be found. Maybe this could be added to the docs?
-- thijs
History
03/15/2006 01:28 PM - Anonymous
A section just like that is already in the default lighty configuration, and has been since r495.
-- ryandesign
03/27/2006 06:32 AM - moo
- Status changed from New to Fixed
- Resolution set to fixed
was fixed in r495
11/15/2006 11:51 PM - Anonymous
- Status changed from Fixed to Need Feedback
- Resolution deleted (
fixed)
That only fixes it for IE, and causes Firefox to start getting errors. A better solution is needed.
12/17/2006 09:16 AM - Anonymous
I've got the same problem. Firefox seems to run into a time out (during transfer appears in german: "angehalten"). Status code is always 206 though server.range-request is disabled. The problem seems tio depend on the size of the requested pdf-File. No problems with apache.
-- Maik Riecken
01/16/2007 08:31 PM - Anonymous
I'm seeing this problem with lighttpd 1.4.11 (the Ubuntu 6.06 LTS package) talking to IE 7, whether I disable range-request or not. Any ideas?
-- mathie
01/24/2007 04:13 AM - Anonymous
I too have same with lighttpd 1.4.8 on debian. Only occours with IE7. Works fine for FF etc and serving from apache works and serving from different server using lighty. Error message I get:
(server.c.960) NOTE: a request for test.pdf timed out after writing 186792 bytes. We waited 360 seconds. If this a problem increase server.max-write-idle
Increasing doesn't help.
02/01/2007 02:06 AM - Anonymous
I've also received reports of this problem with Lighttpd 1.4.13. Apparently also works fine for FF.
Funny thing is, there isn't even an error about timing out in error.log
03/18/2007 10:47 PM - Anonymous
Seeing that I had some troubles with this workaround with Firefox (under windows with the acroreader plugin) I tried a slight tweak of the workaround. Which might work nicely.
$HTTP["useragent"] =~ "\bMSIE" {
$HTTP["url"] =~ "\.pdf$" {
server.range-requests = "disable"
}
}
05/31/2007 10:10 AM - Anonymous
I'm experiencing problems with lighttpd-1.4.15 on FreeBSD 6.1, when trying to access a pdf of 1886325 bytes using Safari 1.3.2 (v312.6) on MacOS X 10.3.9.
When server.range-requests is "disable"d, using on , it hangs the browser for a couple of seconds and then nothing shows up. My access.log shows:
"GET /foo.pdf HTTP/1.1" 200 1886325 "-" "Mozilla/5.0 (Macintosh; U; PPC Mac OS X; sv-se) AppleWebKit/312.8.1 (KHTML, like Gecko) Safari/312.6"
"GET /foo.pdf HTTP/1.1" 200 1886325 "-" "Mozilla/5.0 (Macintosh; U; PPC Mac OS X; sv-se) AppleWebKit/312.8.1 (KHTML, like Gecko) Safari/312.6_Adobe"
My error.log shows nothing.
When I try to disable server.range-requests for IE, the same client side configuration renders almost the whole pdf-document (9 pages out of 12), then it breaks and Safari spews the following error:
"A network error occured. Would you like to close the document or reload it?"
Trying to reload produces the same result, over and over. Again, my error.log is empty.
01/03/2008 05:06 PM - Anonymous
Replying to anonymous:
Seeing that I had some troubles with this workaround with Firefox (under windows with the acroreader plugin) I tried a slight tweak of the workaround. Which might work nicely.
$HTTP["useragent"] =~ "\bMSIE" {
$HTTP["url"] =~ "\.pdf$" {
server.range-requests = "disable"
}
}
Thanks. I need to use this on 1.4.18 as well, and it seems to work.
And I never knew, why those recruiting agencies claimed they wouldn't be able to download my cv.pdf, until I finally tried it myself with IE... :-/
Regards,
Kai-Uwe Nielsen.