Home > database >  RewriteCond works on HTTP but not on HTTPS virtual host
RewriteCond works on HTTP but not on HTTPS virtual host

Time:12-07

i want to rewrite all URLs with trailing ".pdf" to open the pdf-files in the mozilla.pdf.js and have successfully testet following RewriteRule and RewriteCond on my HTTP virtual host (I use apache2 on ubuntu server btw):

example URL to rewrite:

http://server-test.local/downloads/dir2/file5/test.pdf

example target URL after rewrite:

http://server-test.local/libs/mozilla.pdf.js/web/viewer.html?file=/downloads/dir2/file5/test.pdf
RewriteCond %{HTTP_REFERER} !viewer.html
RewriteRule ^(. )(\.pdf)$ http://server-test.local/libs/mozilla.pdf.js/web/viewer.html?file=$1 [R=301,L]

So the RewriteCond prevents another redirect which will cause the mozilla.pdf.js to try to load itself instead of the PDF file and cause an error. (Sry if description is unclear, i am not really into this topic)

Now I've tried to apply exact the same RewriteCond and RewriteRule for my other virtual host (https), which is - except of SSL and a Kerberos implementation - exact the same as the "server-test" virtual host:

RewriteCond %{HTTP_REFERER} !viewer.html
RewriteRule ^(. )(\.pdf)$ https://server-prod.local/libs/mozilla.pdf.js/web/viewer.html?file=$1 [R=301,L]

but it seems that somehow the RewriteCond does not apply. The result is, that the redirect to the mozilla.pdf.js works, but the PDF will not be rendered and an error of the mozilla.pdf.js appears ("invalid PDF structure"), because - this is my theory- there is another redirection, so the mozilla.pdf.js does not load/render the pdf but it tries to load its own viewer.html instead.

I have also tried the following RewriteConds, but no one of them changed the behaviour:

RewriteCond %{REQUEST_URI} !viewer.html*
RewriteCond %{REQUEST_URI} !^/libs/mozilla.pdf.js/web/viewer.html*
RewriteCond !viewer.html

My aim with these RewriteConds is to prevent another (loop) redirection, if the URL before rewrite containing the string "viewer.html", so if the [...]/viewer.html?file=/downloads/dir2/file5/test.pdf is the REQUEST_URI, no more rewrite should happen.

Can someone please explain to me, why the RewriteCond works on the test virtual host (HTTP) but not on the production virtual host (HTTPS)? Except the SSL and the fact that the SSL secured virtual host has a Kerberos implementation, both virtual hosts, their directories and their configs are mostly the same. Is the SSL the problem? And does anyone know how I can fix this issue on the SSL virtual host? I need to find a solution somehow...

I would appreciate every kind of hints/help.

CodePudding user response:

example target URL after rewrite: http://example.com/libs/mozilla.pdf.js/web/viewer.html?file=/downloads/dir2/file5/test.pdf

However, your directive does not currently do this. It redirects (not "rewrites") to http://example.com/libs/mozilla.pdf.js/web/viewer.html?file=downloads/dir2/file5/test - note the missing slash at the start of the file URL parameter value and the missing file extension.

This might be working on one server and not the other if MultiViews is enabled on the former. (This effectively enables extensionless URLs to "work".)

To correct the RewriteRule directive:

RewriteRule \.pdf$ https://example.com/libs/mozilla.pdf.js/web/viewer.html?file=%{REQUEST_URI} [R=301,L]

The file URL parameter will now contain /downloads/dir2/file5/test.pdf.

You will need to clear your browser cache before testing. However, should this be a 301 (permanent) redirect? You mention "rewrite" in your question and you have tagged the question url-rewriting - which this is not. Are you wanting the user to be physically redirected to this new URL? It looks like this should really be an internal rewrite (ie. not exposing mozilla.pdf.js)? In which case, this should be rewritten like the following:

RewriteRule \.pdf$ /libs/mozilla.pdf.js/web/viewer.html?file=%{REQUEST_URI} [L]

an error of the mozilla.pdf.js appears ("invalid PDF structure"), because -thats my theory- there is another redirection, so the mozilla.pdf.js does not load/render the pdf but it tries to load its own viewer.html instead.

Although if that is the case then it would result in a redirect-loop, but the error you are seeing is not indicative of that.

Also, have you confirmed that the Referer HTTP request header is being sent by the browser for this request and is set as expected? The problem here is that the Referer is unreliable. It can be suppressed by the browser for several reasons.

A better approach would be if mozilla.pdf.js set a custom header as part of the request and this could be reliably checked in the mod_rewrite condition.

Alternatively, make the URL-path different from the actual filesystem path. (Although the actual files could be requested if the file-path became known.)


Aside:

So the RewriteCond prevents another redirect which will cause the mozilla.pdf.js to try to load itself instead of the PDF file and cause an error.

It won't try to load "itself". The RewriteRule pattern would already prevent that from happening since it only matches .pdf files (although that isn't what's happening here). The check against the Referer is an attempt to prevent a recursive loop... to prevent viewer.html being repeatedly called and passing the same .pdf file in the file URL parameter.

I'm assuming mozilla.pdf.js makes an HTTP request for the PDF file passed in the file URL parameter. The "problem" (in the case of an external redirect) is to differentiate between a direct request from the user and a request from the script (both are client requests from the browser).

CodePudding user response:

I think, I was able to fix my issue, by additionally adding

RewriteCond %{QUERY_STRING} !file=

to my RewriteConds of my RewriteRule. Now the mozilla.pdf.js opens and show me the PDF file. @MrWhite Thx again for your explanation.

  • Related