Bug 10781 - Can not see the pdf files on my server on the forms page.
Summary: Can not see the pdf files on my server on the forms page.
Status: CLOSED FIXED
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: All (show other bugs)
Version: 2.0.39
Hardware: All All
: P3 critical with 12 votes (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
URL: http://www.orwacog.org
Keywords:
Depends on:
Blocks:
 
Reported: 2002-07-13 22:05 UTC by Steve Fruitt
Modified: 2005-03-20 17:06 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Steve Fruitt 2002-07-13 22:05:48 UTC
I was using Apache 2.0.39 with virtual hosts.  It was fresh load of NT with 
service pack 6a and this apache and Cerberus FTP server. This page has worked 
in the past with 2.0.36.  The pdf files come up as a blank page.  Tried 
everything thinking that it was not the Apache doing it.  Then unistalled 
2.0.39 and installed 1.3.26 and it worked under windows.  But when the 2.0.39 
was running and I went into Mandrake 8.1 then it would only download to my home 
file.  In windows I was using IE 6.0.  My server is a PII 233 with Intel 815EEA 
board hooked to a cable modem.  My phone number is 541-882-7653 or 541-891-8998
(cell phone).  The other web pages run fine except for this little clich.
Comment 1 Ellis Teer 2002-07-16 02:24:17 UTC
Apache 2.0.39 Win2K

Same problem.  Many but not all .pdf links served display as blank page in IE
browser.  Occasional browser crashes also reported.

-Ellis
Comment 2 Joshua Slive 2002-07-16 14:11:08 UTC
I don't know whether this is a client or server problem, but the following
workaround will probably help.  Add this to httpd.conf:
SetEnvIf Request_URI "\.pdf$" no-keepalive
Comment 3 Phillip Ulberg 2002-07-17 17:01:07 UTC
I added the "SetEnvIf Request_URI "\.pdf$" no-keepalive" to httpd.conf and am 
still having problems. Very intermitent, and is not specific to any 
individual .pdf

This is really killing me when I'm currently serving over 15,000 pdf files.

Is this an issue in 1.3.22 and up? 
Comment 4 Ellis Teer 2002-07-17 19:52:44 UTC
Didn't work for me either.

Same with the intermittent.

It is also causing a lot of problems.  I am considering downgrading on an
isolated machine and taking my chances with the security bug 2.0.39 fixed.
Comment 5 Steve Fruitt 2002-07-18 00:43:53 UTC
I have found that 1.3.26 works with PDFs.  The platform somehow got changed to 
alpha and it should be "all".  I think that the severity may have to be changed 
to Critical.


Comment 6 Sid Raghunathan 2002-07-18 23:55:15 UTC
I noticed this behaviour as well. Only in 2.0.39.

My observations were that it occurred sporadically when acrobat was requesting 
the PDF and was the pdf was being byte-served. you can see consecutive requests 
for the same file with sunbsequent requests having an http error code of 206.

this problem is absent in 2.0.36. and 1.3.24.
Comment 7 Andrew J. Smith 2002-07-23 03:30:55 UTC
I also ran into this on 2.0.39 on Win2K.  Went back to 1.3.26 and the problem 
went away.  The problem only appears for me when attempting to view a multi-
page pdf (2+ pages).  The same pdf can be downloaded via "Save As..." and then
opened and viewed fine.  Because of this, I suspect that Sid is correct in that 
the problem has something to do with Acrobat making byte range requests that 
aren't being handled properly.  I've tried both Acrobat 4.0 and 5.0 with 
identical results.
Comment 8 Phillip Ulberg 2002-07-24 16:55:18 UTC
I have done some additional testing on my site with the offending .pdf files, 
and found that this behavior does not occur when I am opening any of the .pdf 
files on my site from my linux box using either xpdf v1.00, or Acrobat Reader 
v5.0.5, mu linux box is - 

RedHat 7.3/2.4.18-5, Mozilla 1.1b browser

I left everything the same on the server - 

Win2K Server, Apache 2.0.39, Sun ONE ASP(Chilisoft ASP)

I will do this same testing now on MacOS9/MAcOS X and see what happens.

Phillip
Comment 9 Chris Sims 2002-07-24 17:11:43 UTC
My experience matches that of Andrew J. Smith, except that my server was on NT, SP6a.  Also, I noted 
that the problem does not appear with the Acrobat plugin used in the Opera 6.04 browser, but does 
appear in Netscape 4.x, IE 5.5, and Mozilla 1.0.
Comment 10 Mark 2002-07-26 17:24:43 UTC
I ran into this same problem a couple days ago.

I agree that the issue is related to the Acrobat 
document being byte-served. I've tried adding "SetEnvIfNoCase Request_URI "\.pdf$" 
nokeepalive" to my config, but still have the same problem. I also tried all the following 
simultaneously, and still experience the problem:

SetEnv nokeepalive
SetEnv 
downgrade-1.0
SetEnv force-response-1.0

In order to get around this issue I had to switch to 
using a backup server which has 2.0.36 . I use the exact same config file on the 2.0.36 machine as 
the 2.0.39.

Here is the HTTP conversation I observed (on the server) when the PDF didn't 
transfer properly:


GET /DP/documents/deliverables.pdf HTTP/1.1
Accept: 
application/vnd.ms-excel, application/msword, application/vnd.ms-powerpoint, 
image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*
Referer: 
http://test.statst.org/DP/documents/deliverables.htm
Accept-Language: en-us
Accept-
Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows 95)
Host: 
test.statst.org
Connection: Keep-Alive


HTTP/1.1 200 OK
Date: Fri, 26 Jul 2002 
16:40:12 GMT
Server: Apache/2.0.39 (Win32)
Last-Modified: Wed, 12 Jun 2002 18:49:47 
GMT
ETag: "25b-2019c-1bf5992b"
Accept-Ranges: bytes
Content-Length: 
131484
Connection: close
Content-Type: application/pdf
X-Pad: avoid browser 
bug


GET /DP/documents/deliverables.pdf HTTP/1.1
Accept: */*
Accept-Encoding: 
gzip, deflate
Range: bytes=8192-
Unless-Modified-Since: Wed, 12 Jun 2002 18:49:47 GMT
If-
Range: "25b-2019c-1bf5992b"
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows 
95)
Host: test.statst.org
Connection: Keep-Alive


HTTP/1.1 206 Partial 
Content
Date: Fri, 26 Jul 2002 16:40:19 GMT
Server: Apache/2.0.39 (Win32)
Last-
Modified: Wed, 12 Jun 2002 18:49:47 GMT
ETag: "25b-2019c-1bf5992b"
Accept-Ranges: 
bytes
Content-Length: 123292
Content-Range: bytes 8192-131483/131484
Connection: 
close
Content-Type: application/pdf


GET /DP/documents/deliverables.pdf 
HTTP/1.1
Accept: */*
Range: bytes=25401-31023, 31024-61023, 61024-91023, 91024-121023, 
121024-126940
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 
5.5; Windows 95)
Host: test.statst.org
Connection: Keep-Alive
Cache-Control: no-
cache


GET /DP/documents/deliverables.pdf HTTP/1.1
Accept: */*
Range: 
bytes=130646-131483
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 
(compatible; MSIE 5.5; Windows 95)
Host: test.statst.org
Connection: Keep-Alive
Cache-
Control: no-cache


HTTP/1.1 206 Partial Content
Date: Fri, 26 Jul 2002 16:40:19 
GMT
Server: Apache/2.0.39 (Win32)
Last-Modified: Wed, 12 Jun 2002 18:49:47 GMT
ETag: 
"25b-2019c-1bf5992b"
Accept-Ranges: bytes
Content-Length: 838
Content-Range: bytes 
130646-131483/131484
Connection: close
Content-Type: application/pdf


GET 
/DP/documents/deliverables.pdf HTTP/1.1
Accept: */*
Range: bytes=127823-
128846
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; 
Windows 95)
Host: test.statst.org
Connection: Keep-Alive
Cache-Control: no-
cache


HTTP/1.1 206 Partial Content
Date: Fri, 26 Jul 2002 16:40:19 GMT
Server: 
Apache/2.0.39 (Win32)
Last-Modified: Wed, 12 Jun 2002 18:49:47 GMT
ETag: "25b-2019c-
1bf5992b"
Accept-Ranges: bytes
Content-Length: 1024
Content-Range: bytes 127823-
128846/131484
Connection: close
Content-Type: application/pdf

Comment 11 Herman Hardenbol 2002-08-01 15:04:46 UTC
no problems with small pdf's; under 15 kb
Comment 12 William A. Rowe Jr. 2002-08-06 06:52:27 UTC
  Yup.  That was a bug.  Fixed in CVS HEAD, and with luck, it will make
  it into 2.0.40 in the works this week.

  Prior to any sendfile if we had any tailing text buffer, we clobbered any 
  header text buffer that was constructed.
Comment 13 Richard 2002-08-22 17:48:01 UTC
I'm currently seeing a similiar issue, and wondering if there's any fix for 
this currently out for Linux.  I've tested this on 2.0.36, 2.0.39 and 2.0.40 
and each time we're receiving blank pages when accessing PDFs from clients 
running IE with Acrobat Reader 4.x.   We're running Linux 7.3.

I've tried the KeepAlive and SetEnvIf suggestions from below and they don't fix 
the problem.  

The PDF files are actually being served off of a Win2K box that's running IIS, 
however the requests are proxied through the Apache servers (ProxyPass).  When 
going to a URL directly on the Win2K box, they load fine.

-Richard
Comment 14 William A. Rowe Jr. 2002-08-22 18:23:58 UTC
>  "We're running Linux 7.3.  The PDF files are actually being served off of 
>   a Win2K box that's running IIS, however the requests are proxied through 
>   the Apache servers (ProxyPass).  When going to a URL directly on the 
>   Win2K box, they load fine."

If you serve the .pdf's directly from the Linux 7.3/Apache 2.0.40 box, what is
the result?  I'm guessing that we somehow corrupt the byteranges through the
proxy, which doesn't fall under the scope of this bug.

If you cannot serve the .pdf's directly from your 7.3/2.0.40 server, please
reopen this bug and update the OS version.  If it turns out that this is a
proxy bug only, please start a new incident for "mod_proxy/http_proxy cannot 
forward byterange requests."
Comment 15 Paul Slootman 2002-10-17 08:19:58 UTC
> If you cannot serve the .pdf's directly from your 7.3/2.0.40 server, please
> reopen this bug and update the OS version.  If it turns out that this is a
> proxy bug only, please start a new incident for "mod_proxy/http_proxy cannot 
> forward byterange requests."

I ran into problems with 2.0.40 on Solaris 2.6 (sparc) serving .pdf's.
I just tried again with 2.0.43, and still it won't work.

I did a quick and dirty workaround:

Action cat-pdf /cgi-bin/cat-pdf.sh
AddHandler cat-pdf .pdf

cat-pdf.sh is a simple shell script:

#!/bin/sh

echo "Content-Type: application/pdf\r";
echo "\r";
exec /bin/cat "$PATH_TRANSLATED"


Apparently as now no timestamp info is passed, acrobat is convinced into
not requesting byte ranges. However, this is just a workaround and the
bug in Apache is real.

Apart from this, no big problems with 2.0.40 + PHP4.2.2, perhaps apart from
the fact that "apachectl restart" sometimes leaves the server inoperative for
up to 20 minutes(!), apparently some child process hangs around too long.
"apachectl graceful" works fine.
Comment 16 William A. Rowe Jr. 2002-12-30 18:14:20 UTC
  Reclosing this bug ... the problem with *local* pdf transmissions was gone.

  r.e.  Richard 2002-08-22 17:48  ...  See bug 11993 where we are tracking
  that specific problem.