htaccess redirect help

[globex]

I'm looking for help with my rewrite rule in .htaccess. What I need:

When going to www.mysite.com/page.php check to see if www.mysite.com/pages/page.php exists, if it does redirect to www.mysite.com/#page.php, if it doesn't redirect to www.mysite.com/#404.php

Same should occur for pages nested in directories. So when going to www.mysite.com/directory/page.php check to see if www.mysite.com/pages/directory/page.php exists, if it does - redirect to www.mysite.com/#directory/page.php otherwise redirect to www.mysite.com/#404.php

What I have right now is:

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ index.php#$1 [QSA,L]

Which doesn't work at all. Everything seems to get redirected to www.mysite.com/index.php without any hash values being passed at all. And I'm also not sure how to include the if statement in there to check to see if file exists inside www.mysite.com/pages/

Your help would be greatly appreciated. Thank you.

[g1smd]

You should never "redirect" to an error page, otherwise the user will not see the correct error code.

There's a huge terminology problem with the question, specifically URLs exist on the web whether or not they resolve to content, and files exist on the server. The two things are not the same, not at all.

Your question mentions redirects, but your example code is for a rewrite. I don't really understand what you actually want to do. From what I can glean you are going to need a redirect and a rewrite, but first what are you actually trying to achieve, and why do you think you want a # in the URL?

As for those #values, they are not passed to the server when they appear in a URL out on the web. They refer to named anchors within the page and are evaluated by the browser once the entire page has been sent to the browser. They can't appear in a server-internal filepath, they have no meaning at all inside the server.

They are sometimes used with AJAX to fetch things from a server, but this requires additional JS functions on the page to do that, and the browser runs those JS functions, not the server.

[globex]

You're right, when I said redirect I meant rewrite. I'm using AJAX to parse the hash value to render the page and I'm using a template system which is why I want all the pages to go to index.php.

I want to render the error pages through my index.php file too. But that can be the second part of the problem.

For now I guess, I just need to rewrite all requested pages to index.php#page.

[g1smd]

I want to render the error pages through my index.php file too.

I'm not sure that you can do this in the way you might envisage, as for 'proper' error pages you need to send the HTTP Header with correct status code as well as any (optional) human readable error message HTML page.

Surely this is a job entirely for the PHP script on the server, nothing to do with .htaccess? The PHP script should check whether the content exists and send it out, or send an error message if there's no content. I don't see this as a job for .htaccess at all.

The job of .htaccess is to take certain incoming URL requests (those that look like they should be handled by the PHP script) and pass them on to the PHP script for handling. The PHP script should then check if the content exists, and either send it out or send an error message.

[globex]

Alright, I'll deal with my error pages inside of PHP. How about getting the rewrite working correctly? Right now it simply rewrites everything to index.php without the hash value of the requested page.

[g1smd]

# has no meaning inside a server. Inside the server you are dealing with filepaths on the hard drive.

# has a meaning in a URL, but it is the browser that evaluates where on the page that named anchor is located, and scrolls to it.

The # value is not sent to the server, at least not as #something.

[globex]

Hmm. So would you recommend I rewrite to index.php?url=mypage then and use PHP to redirect that to the hash value?

[g1smd]

Once you have rewritten the URL request to the internal file at index.php and passed the parameter url=mypage to the script at that location, the script can simply deliver the content the user wanted to see.

There's no 'redirect' required, is there?

[globex]

Well, I'm actually using Javascript to parse the URL (hence the use of the client-side hash value). But after reading some articles online I think I've figured out the best way to achieve this.

- When a user to go to www.mysite.com/page.php I get .htaccess to rewrite the user to www.mysite.com/index.php?url=page.php
- index.php then saves the requested page 'page.php' into a cookie
- Javascript reads the cookie information and renders the requested page

Seems to be working great. Thank for your help and advice g1smd.

[globex]

Actually one thing that's still bugging me is that it's still rewriting requests to pages that don't exist. Is there a way to have it correctly return a 404 error if the page doesn't exist? Here's the code I've got at the moment:

# Rewrite pages through index.php via ?gdUrl
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ index.php?gdUrl=$1 [QSA,L]

I can do a check to see if the requested file exists with PHP but it'd be better if Apache returned the correct error code already.

For some reason the code I have now will rewrite anything I enter into as my URL to index.php?gdUrl=request

[g1smd]

The file index.php always exists, so will natively return 200 OK for all requests unless you arrange for the PHP script to do something else to override that.

The parameter and value is not a part of the URL. It is data attached to the URL. That parameter is intended to be processed by the resource located at index.php inside the server.

That is, for non-valid requests your script should return:

<?php header("HTTP/1.0 404 Not Found"); ?>


This header must be the very first thing the script sends out for non-valid requests.


It's not the job of .htaccess to do that in this case.

[jdMorgan]

I want to step in only long enough to point out that if JS is used to generate "pages", and that page-generation depends on cookies, then the site will likely not perform well in search.

At present search engines index and assign ranking by URLs -- not by "pages" or "sites," just by individual URLs. And although they're making progress toward a rudimentary understand of JS, it's not sufficient to the task of "understanding" a design such as this. Also, at present, cookies support in Search engines is spotty to non-existent. Some other server-side mechanism may be needed to support search engines' indexing of your site.

Jim

[globex]

Alright, I've set up PHP to generate the 404.

As for the search, I'm hoping the fact that the pages can be accessed both via www.mysite.com/#page and www.mysite.com/page will help with that. As well, the sitemap for my site will have correct links too.

The pages can be accessed both via the proper URL /page and hash value /#page. The reason I'm using the hash is that once you're inside the site, it's a much more enjoyable user experience to have the pages get generated on the fly with AJAX.