Bug #171

Esoteric Bug with acrobat 7 "fast web view" and request ranges.

Added by Anonymous over 9 years ago. Updated about 4 years ago.

Status:FixedStart date:
Priority:UrgentDue date:
Assignee:-% Done:

0%

Category:core
Target version:1.4.19
Missing in 1.5.x:

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

History

#1 Updated by Anonymous over 9 years ago

Some thoughts...

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

#2 Updated by jan about 9 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"
}

#3 Updated by Anonymous about 9 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

#4 Updated by jan almost 9 years ago

it should work in 1.4.6 again.

#5 Updated by Anonymous almost 8 years ago

This fix only works for IE, it causes Firefox to start getting errors.

#6 Updated by Anonymous almost 8 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.

#7 Updated by stbuehler over 6 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.

#8 Updated by Anonymous over 6 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

#9 Updated by Anonymous over 6 years ago

Agreed, I think the config should be called something snotty:

handle.retarded-adobe-reader = "true" ;)

#10 Updated by Olaf-van-der-Spek about 4 years ago

What versions of IE and Reader are affected?

Also available in: Atom