Jump to content

rewrite urls: .php to .html and server access .html to .php


Recommended Posts

Hi,

I'm trying to set up a mod rewrite so that urls entered like this:

http://mydomain.com/home.html

access the php equivalent:

http://localhost/home.php

 

That's done easily with this:

RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d

RewriteRule ^(.*)\.html $1.php [L]

 

Now what I'm trying to do is add an extra bit so that if the url in the address bar ends in php it changes it (in the address bar) to html.

so this:

http://localhost/home.php

would become this:

http://localhost/home.html

 

This isn't just the opposite to what I've got above. I'm wanting to re-direct all php files when entered in the address bar to html.

Then the original re-direct read it as php. odd I know.

The following code will re-direct all php files to html, but I have to remove the two rewrite condition lines.

RewriteEngine On
RewriteBase /

RewriteRule ^(.*)\.php$ $1.html [R,NC]

 

I can't seem to get them to work together.

in lame terms I'm basically wanting to re-write all .php urls in the address bar to .html

mydomain.com/index.php

to

mydomain.com/index.html

 

but always have the server accessing it as .php (wether it says .php or .html)

Apache has no control over your client's Browser URL bar unless you redirect back (which causes it to update itself and re-request the file).  HTTP is a stateless transaction and your browser is oblivious to server rewriting.

 

You can do this with javascript tho' ;)

Well if a user types this into the address bar:

http://www.mydomain.com/page.php

I want to re-direct to:

http://www.mydomain.com/page.html

which I do with this:

RewriteRule ^(.*)\.php$ $1.html [R,NC]

 

But then I want to get it to still access the .php file. The reason is so that to the user all files end with .html, although they're .php.

So I tried using this as a rewrite, hoping that it would re-direct the user to .html and then access the .php:

RewriteEngine On
RewriteBase /
#RewriteCond %{REQUEST_FILENAME} !-f
#RewriteCond %{REQUEST_FILENAME} !-d

RewriteRule ^(.*)\.php $1.html [NC,R]
RewriteRule ^(.*)\.html $1.php [NC]

but it bring up an error:

Found

 

The document has moved here.

Linking to the exact same url.

I thought that perhaps not re-directing the html -> php one would work, but obviously not.

IMHO this is rather a circular requirement and it would be almost certain that you'd end up with circular references (not good!)

Developing rewrite rules with circular design requirements would be painful and debugging a nightmare.

 

Although, in theory, it might be possible to achieve your *immediate* question you may not end up with what you really want. It might be better to think the basic design through from the start rather than keeping an unsatisfactory design and trying to batter it with mod_rewrite until it "fits" how you originally thought it should work.

 

Not sure how many users would really type in domain/filename.php - that would tend to come from a link in your own HTML content

 

If you use PHP then redirecting PHP "away" from native PHP files isn't really all that good an idea. It would be better to do things the other way around. E.g. rewriting /page-x.html  to /page-x.php (hidden) or virtual folders  /page/ -> /page-x.php (hidden).

You can rewrite requests for HTML files which match specific criteria (filename or location) as PHP without the user "seeing" if you don't redirect  e.g. domain/folder/public.html -> domain/phpscripts/private.php. However I wouldn't rely on such obscurity as a method of security since the user could "guess" the actual script names.

 

Redirecting or remapping from PHP to HTML then back to PHP doesn't seem a good way to do things to me.

Hiding what happens in the client's URL bar is a common request but the solutions are often put in the context of realising that this is a limitation near the end of the design rather than designing with this in mind from the get-go.

 

Look at Wikipedia which uses virtual folders, almost certainly rewriting to PHP/SQL scripts to retrieve the data.

(example: http://en.wikipedia.org/wiki/Mod_rewrite  -> redirects /wiki/* to "hidden" scripts, PERL, PHP, ASP or whatever)

 

As I recall there have been a number of recent postings dealing with similar issues - might be worth searching  ;)

well basically I'm re-doing a current website which has google listings. What I'm wwanting to do is just get all of the google listings and things to show as .html instead of .php..

so in effect blocking direct access to .php through the url bar, so files are always accessed as .html, but in the background they are the .php files.

 

My first snippet of code is the closest to what I want:

RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d

RewriteRule ^(.*)\.html $1.php [L]

It switches the .html with .php without the re-direct so the user doesn't know.

I'm just not wanting people to access files by typing in .php extensions into the url bar.

Seems to me the easiest solution would be to name your php files with the html extension, then have your server parse them as php.

 

AddType application/x-httpd-php .html

Yeah I thought of that, but I don't have access to the php.ini file and also I seem to remember reading somewhere that if anyone downloaded the html file it would have all of the php code inside it. Unlike a php file, where it wold only display the html output.

Or am I wrong?

Interpreting all as PHP you'd  have a slightly increased load as PHP open brackets would need to be tested for <? ?> etc. but otherwise plain HTML would be returned where these were not found and the PHP parser (should) not be used. (AFAIK)

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.