Bug #171
closedEsoteric Bug with acrobat 7 "fast web view" and request ranges.
Description
I have just put a site into production with lighty: http://www.toolwire.com
(an irc log follows, I apologize for its verbosity)
Acrobat Reader 7 embedded in IE as a plugin under IE6 would request a PDF, and say it had only received some random number of k - like "3.67k of 460k" etc. Eventually the operation would time out. Downloading files to disk then viewing them always worked fine. Turning off "allow fast web view" resolved the issue completely.
However, a lot of people use acro7/IE6 and they have fast web view turned on.
This same operation (downloading a PDF) is known to work with Apache 1.3 and IIS with an IE6 / acro7 embedded client.
I can only suspect there is something too strict, or possibly broken, about the way lighty responds to range requests.
At chipig's suggestion, I did a tcpdump on my problematic PDF download attempts and an IE6 client. I saw the following:
GET /files/Toolwire-CiscoCaseStudy.pdf HTTP/1.1 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/msword, application/vnd.ms-powerpoint, application/x-shockwave-flash, */* Referer: http://beta.toolwire.com/customers/case_studies Accept-Language: en-us,ja;q=0.5 Accept-Encoding: gzip, deflate Range: bytes=7767- Unless-Modified-Since: Wed, 29 Jun 2005 19:49:05 GMT If-Range: "-1917344833" User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; T312461) Host: beta.toolwire.com Connection: Keep-Alive Cookie: _session_id=b5ec0e73230073e253000eb56e0082ca 19:28:56.964984 IP (tos 0x0, ttl 64, id 30068, offset 0, flags [DF], length: 1372) 172.20.0.176.www > dsl092-016-004.sfo4.dsl.speakeasy.net.9140: . [tcp sum ok] 24519:25851$ E..\ut@.@.......B\...P#.....T.b.P.0..k..HTTP/1.1 206 Partial Content Date: Sat, 09 Jul 2005 02:28:56 GMT Content-Length: 825980 ETag: "-1917344833" Accept-Ranges: bytes Content-Type: application/pdf Content-Range: bytes 7767-833746/833747 Server: lighttpd/1.3.14 <content>
GET /files/Toolwire-CiscoCaseStudy.pdf HTTP/1.1 Accept: */* Range: bytes=832723-833746, 825555-832722, 11530-825554 Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; T312461) Host: beta.toolwire.com Connection: Keep-Alive Cache-Control: no-cache Cookie: _session_id=b5ec0e73230073e253000eb56e0082ca 19:28:57.187396 IP (tos 0x0, ttl 64, id 34282, offset 0, flags [DF], length: 40) 172.20.0.176.www > dsl092-016-004.sfo4.dsl.speakeasy.net.6200: . [tcp sum ok] ack 355 win 6$ E..(..@.@.......B\...P.8.On+.G.#P.. l".. 19:28:57.187953 IP (tos 0x0, ttl 64, id 34283, offset 0, flags [DF], length: 1372) 172.20.0.176.www > dsl092-016-004.sfo4.dsl.speakeasy.net.6200: . [tcp sum ok] 1:1333(1332$ E..\..@.@.......B\...P.8.On+.G.#P.. )...HTTP/1.1 206 Partial Content Date: Sat, 09 Jul 2005 02:28:57 GMT Content-Length: 822522 ETag: "-1917344833" Accept-Ranges: bytes Content-Type: multipart/byteranges; boundary=fkj49sn38dcn3 Server: lighttpd/1.3.14 --fkj49sn38dcn3 Content-Range: bytes 832723-833746/833747 Content-Type: application/pdf n <content> (I assume "n" is the first line of content returned by the server)
irc log:
[6:44pm] turing: I have a fairly major but mysterious problem [6:44pm] turing: I just launched with lighty, this site: [6:44pm] turing: http://www.toolwire.com/ [6:45pm] turing: if I attempt to download PDFs, I get random delivery failures (incomplete file delivery) [6:48pm] chipig: os/filesystem? [6:49pm] chipig: also, corrupt in what way? wget+md5? [6:49pm] turing: chipig: a warning [6:49pm] chipig: or just acrobat has issues? [6:49pm] turing: heh, I was going to say that [6:50pm] turing: but I'm being paranoid [6:50pm] turing: I looked in the error logs and I see jacko - couple fcgi restarts [6:50pm] chipig: the PDFs are static files, right? [6:50pm] turing: yes [6:50pm] turing: direct file serves [6:50pm] chipig: hm. Acrobat does some crazy things with the Range header [6:50pm] turing: it's _so_ weird [6:51pm] turing: sometimes I get 4-20k of the files [6:51pm] chipig: to make the .pdf look like it downloads faster, it downloads different parts of the file [6:51pm] turing: other files download perfectly and completely [6:51pm] turing: idiots [6:51pm] turing: [6:51pm] chipig: no, its actually good. [6:51pm] chipig: but, anyways. [6:51pm] chipig: try turning off sendfile [6:51pm] turing: good if it works [6:51pm] turing: I already have it off [6:52pm] chipig: oh. [6:52pm] chipig: NFS or anything else weird? [6:52pm] turing: no [6:52pm] turing: utterly boring [6:52pm] chipig: well. Hmm. [6:52pm] turing: I'm inclined to think 'acrobat' because some PDFs work fine [6:52pm] chipig: why is sendfile already off ? [6:53pm] turing: oh, because I ran into it a while ago on a 2.4kernel [6:53pm] turing: and jan told me to turn it off [6:53pm] turing: so I did [6:53pm] chipig: turing: get some etheral dumps. See how its requesting data. Make sure lighttpd is replying with the correct size replies. [6:53pm] chipig: heh [6:54pm] chipig: (i tend to agree with the theory that it could easily be broken acrobat, it has always been problematic with apache too) [6:54pm] chipig: which version of acrobat? [6:54pm] turing: 7 [6:54pm] chipig: hmm [6:54pm] turing: the "IE plugin" [6:54pm] chipig: 7 is better than 5.x [6:54pm] chipig: oh [6:54pm] turing: everything that downloads to disk and opens after works fine [6:54pm] chipig: right [6:54pm] turing: which is why I think it's probably acro, but [6:55pm] turing: it doesn't happen with other sites [6:55pm] chipig: well, it could be a lighttpd handling the range requests wrong somewhere [6:55pm] chipig: that would cause just the plugin to fail [6:55pm] chipig: but, I don't know the lighttpd code well enough to tell you if thats reasonable. [6:55pm] turing: ah [6:55pm] chipig: is an apache person [6:55pm] turing: ah [6:56pm] chipig: is it with really old version of IE too? [6:56pm] turing: no [6:56pm] turing: 6 [6:56pm] chipig: like 5.0123123123123 or something? [6:56pm] chipig: bah. stop making this hard [6:57pm] chipig: so, my suggestion is look at the network layer [6:57pm] turing: ok [6:57pm] chipig: see what bits are flying [6:57pm] turing: wow [6:58pm] turing: ethereal needs an insane set of dependencies [6:58pm] turing: is there anything else that works? [6:58pm] turing: tcpdum [6:58pm] chipig: on windows? [6:58pm] turing: oh no debian [6:58pm] chipig: oh. ya, you can use tcpdump [6:58pm] turing: I'd like to monitor on the server [6:58pm] turing: k [6:58pm] chipig: just set the capture size.. -s 0 [6:58pm] chipig: then it will capture whole packets [6:58pm] chipig: and.. write it out to afile [6:59pm] turing: installing [6:59pm] turing: of course [6:59pm] turing: on os x [6:59pm] turing: workee [6:59pm] turing: heh [7:00pm] turing: hm, is there a port option on tcpdump? [7:01pm] turing: i.e. so I can dump comm between :80 and whatever is talking to 80? [7:01pm] turing: I don't see it [7:03pm] turing: whoa [7:03pm] turing: got it [7:03pm] turing: doesn't seem to decode [7:03pm] turing: looking [7:09pm] turing: ok [7:09pm] turing: I have a full dump [7:09pm] turing: I see acro requesting ranges [7:09pm] turing: Range: bytes=832723-833746, 825555-832722, 3771-825554 [7:10pm] turing: response is here: [7:10pm] turing: http://rafb.net/paste/results/FuxM?6e72.html [7:12pm] turing: ok [7:12pm] turing: I see my multiple requests [7:12pm] turing: it _looks_ as if lighty is responding properly [7:12pm] nextangle left the chat room. [7:12pm] turing: but I don't know HTTP (especially HTTP/1.1 206 Partial Content) well enough to say for sure [7:14pm] turing: hm [7:15pm] turing: any ideas? [7:18pm] turing: ok [7:18pm] turing: cilent just put one of the PDFs that don't work on the public site [7:18pm] turing: onto an IIS machine on their internal network [7:18pm] turing: and it _worked_ [7:18pm] turing: so it does appear to be lighty [7:19pm] turing: (or more likely lighty works and everything is broken, and everyone coded to the broken behavior [7:19pm] turing: er, everything _else_ [7:24pm] turing: ........ [7:24pm] turing: scheisse [7:24pm] turing: this breaks only with lighty [7:25pm] turing: ok, bummer [7:33pm] turing: anyone awake? [7:40pm] courtenay
btw,
THANKS for lighy. It freaking rules. ;)
Updated by Anonymous over 19 years ago
Some thoughts...
- Can you attach the raw tcpdump files, one for Apache and one for lighty? (by using tcpdump
with -w, e.g. tcpdump -s 0 -w apache.tr port 80) - There's some notes in the apache documentation that may offer some hints, notably:
http://httpd.apache.org/docs/1.3/misc/known_client_problems.html
The Adobe Acrobat Reader plugin makes extensive use of byteranges and prior to version 3.01 supports only the multipart/x-byterange response. Unfortunately there is no clue that it is the plugin making the request. If the plugin is used with Navigator, the above workaround works fine. But if the plugin is used with MSIE 3 (on Windows) the workaround won't work because MSIE 3 doesn't give the Range-Request clue that Navigator does. To workaround this, Apache special cases "MSIE 3" in the User-Agent and serves multipart/x-byteranges. Note that the necessity for this with MSIE 3 is actually due to the Acrobat plugin, not due to the browser.
-- sit
Updated by jan over 19 years ago
- Status changed from New to Fixed
- Resolution set to fixed
The bug was reproducable, but from my few we don't do anything wrong.
in r482 (part of 1.3.16) added server.range-requests = "enable" and gives you the possibility to workaround this problem by using:
$HTTPurl =~ "\.pdf$" {
server.range-requests = "disable"
}
Updated by Anonymous over 19 years ago
http://httpd.apache.org/docs/2.0/misc/known_client_problems.html
all these should be done in doc/lighttpd.conf and possibly implement some new options and write some hack codes. and pdf problem should be gone
-- Xuefer <xuefer
Updated by Anonymous about 18 years ago
This fix only works for IE, it causes Firefox to start getting errors.
Updated by Anonymous about 18 years ago
Using lighttpd-1.4.11, this bug is still arround with IE 6/7.
Disabling the http/1.1 protocol and using v1.0 only in IE config
corrected the problem.
I can confirm the last comment with the proposed workaround, the following seems to work (until now):
$HTTP["url"] =~ "\.pdf$" {
$HTTP["useragent"] =~ "MSIE" {
server.range-requests = "disable"
}
}
Don't know which one is the culprit (the pdf plugin, ie or lighty) but this works just fine with apache.
Updated by stbuehler almost 17 years ago
- Status changed from Need Feedback to Fixed
- Resolution set to fixed
I think the problems with Firefox and other browsers may be related to bug #1449, fixed in r2090.
Updated by Anonymous over 16 years ago
Using lighttpd 1.4.19, I had the same problem.
This workaround worked for me,
$HTTP["url"] =~ "\.pdf$" {
$HTTP["useragent"] =~ "MSIE" {
server.range-requests = "disable"
}
}
but it is really a bug imo that you have to put something in your config after looking at the bugs to fix an issue like this. Even if it is a problem with adobe reader, I almost lost customers because they couldn't open their pdf files.
-- pelletiermaxime
Updated by Anonymous over 16 years ago
Agreed, I think the config should be called something snotty:
handle.retarded-adobe-reader = "true" ;)
Updated by Olaf-van-der-Spek about 14 years ago
What versions of IE and Reader are affected?
Also available in: Atom