244048 - Acrobat Reader 5.1 fails to load/show documents for sites requiring the browser to provide a referrer URL

Status: RESOLVED WORKSFORME

(Plugins Graveyard :: PDF (Adobe), defect)

Description

[Rolf Sponsel]

User-Agent:       Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.7) Gecko/20040514
Build Identifier: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.7) Gecko/20040514

Acrobat Reader 5.1 fails to load/show documents for sites requiring the browser
to provide a referrer URL.

Clicking on a link to a pdf file, in a web page, which normally launches the
Acrobat Reader Plugin fails when the Web Server restricts requests by referrer
(i.e. HTTP_REFERER).

Checking the Web Server's referer_log file shows that a[ny] request made by
Mozilla (1.7rc2) to a pdf document actually performs TWO requests to the Web
Server, and only the one first does provide a referer value. Thus, the Web
Server rejects the second request, and that is most likely the reason for this
issue.

This issue is most likely resolved if that second request also provides the
referrer information (if that second request is needed at all), as does the
first request.


Reproducible: Always
Steps to Reproduce:
1. Create a Web Page with a link (e.g. in index.html as in my case) to a pdf
document on your Web Server (Apache). 
2. Visit that page, clicking the link starts Acrobat Reader and displays the pdf
document as expected.
3. Now, configure your Web Server to require the HTTP_REFERER property to be
defined/provided (i.e. set to server from which our documents are provided) in
order to allow access to that pdf document. (In my particular case I do it with
Apache's 'SSLRequire %{HTTP_REFERER} =~ m|^https://server.dom/|' directive.)
4. Restart the Web Server, and revisit the Web Page.
5. Clicking the link to the pdf document now no longer show the pdf document.

Actual Results:  
- Studying Apache's error_log reveals these messages:

[Wed May 19 14:08:26 2004] [notice] Apache/2.0.49 (Unix) mod_ssl/2.0.49 OpenSSL
0.9.7d configured -- resuming normal operations
[Wed May 19 14:09:32 2004] [error] [client ###.###.###.###] access to
/web/Document.pdf failed, reason: SSL requirement expression not fulfilled (see
SSL logfile for more details)

- The ssl_request_log reveals:

[19/May/2004:14:09:31 +0200] ###.###.###.### TLSv1 DHE-RSA-AES256-SHA "GET
/web/Document.pdf HTTP/1.1" 155566
[19/May/2004:14:09:32 +0200] ###.###.###.### TLSv1 DHE-RSA-AES256-SHA "GET
/web/Document.pdf HTTP/1.1" 687

Finally the ssl_referer_log reveals:

https://server.dom/web/ -> /web/Document.pdf
- -> /web/Document.pdf


Expected Results:  
It should have displayed the pdf document in a page running the Acrobat Reader
plugin, just as it does when the Web Server does NOT require a valid referer.

The ssl_referer_log entries are identical in both cases (as they should be,
although IMHO, they most likely are wrong in both cases).


In the case of when no referer is required the ssl_request_log looks like this:

[19/May/2004:14:05:29 +0200] ###.###.###.### TLSv1 DHE-RSA-AES256-SHA "GET
/web/Document.pdf HTTP/1.1" 155566
[19/May/2004:14:05:29 +0200] ###.###.###.### TLSv1 DHE-RSA-AES256-SHA "GET
/web/Document.pdf HTTP/1.1" 139893

By comparing the second line above with the second line pasted in the "Actual
Results" section above, one can see that it only differs in the length of what
has been served.


If you happen to need more information, please let me know.

Best Regards,
Rolf Sponsel

Comment 1

[Jesiah S]

WFM when I click on the first pdf link on
http://www.google.com/search?q=test+filetype%3Apdf&btnG=Google+Search
does this only happen on https sites?  Can you set up a test server?
I think the real problem is the second GET request and the fact the server seems
to send two diffrent file when you do not require the referer.
There is also a newer version of Acrobat for Windows if that is the problem.
LInux 20040603006

Comment 2

[Rolf Sponsel]

Hi Jesiah,

I know there is a newer Acrobat Reader, but that one requires Internet Explorer
5.0.1 or a later one to be installed. And we don't want that, do we? ;-)

Anyway, I just tried to reproduce the problem but don't seem to be able to do it
anymore. Now it seems to work as expected. That's great! :-)

Now what could have been the problem?

Really I don't know, but at first I thought it could be due to a patch that I
applied to mod_ssl for apache-2.0.49 in order to avoid apache crashing when
downloading ssl-encrypted files > 100k. Then I found out that I had done that
tre days before I reported this issue. BTW, that potential Denial Of Service fix
  has incorporated in the recently announced apache-2.0.50 release.

Therefore, the only change that has been made in my environment is that I have
upgraded Mozilla from 1.7rc2 to 1.7 final. Thus it seems very likely that the
issue was resolved by upgrading Mozilla to 1.7 final.

I thus suggest we close this bug.

I will retest this as soon that I have upgraded my apache to 2.0.50 (and also
study the log files more in detail).

Should it appear again (which I really don't expect it to) then we will just
have to reopen the bug.

BTW, I believe you have a point in that the problem might have had someting to
do with Mozilla (Acrobat Reader plugin) being feed with two different, although
not pages, response codes (of which one was the "access/request denied" code).

Best Regards,
Rolf

Comment 3

[Jesiah S]

Thanks for replying, marking as WORKSFORME.  Just reopen if you see it again.