but when you add a forward slash (/) to the end of any page url on the site (eg [mysite...] instead of getting a 404 error page (which you should get) you get a the page without any images and all links on the page add the /mypage.htm/ bit in their url.

This isn't sufficiently clear, as we have no idea what "the /mypage.htm/ bit" means to you or should mean to us.

The problem is likely a combination of the use of page-relative included-object linking, and either MultiViews enabled, or a bit of mod_rewrite code gone wrong.

All servers, configuration rules, and URL-sets are different; Please tell us more about yours...

Jim

Thanks for such a quick response and for taking an interest.

Here is some more information:

I have set up some test pages on a site that we use for testing purposes only.The url is http://www.example.com

There are two links on the page both pointing to another test page on the same site. One has the url not ending in a / and the other one does end with a / by clicking on these it will show the problem if you look also at the url in the address box of your browser.

I have put the contents of the .htaccess file on the first page.

The site is on a Unix server with the following setting:

WebDav active
Fast CGI active
SSL Support active
PHP Module active

Hoe this is enough info.

Regards

[edited by: jdMorgan at 12:28 am (utc) on Nov. 5, 2009]
[edit reason] example.com [/edit]

I guess the moderator has changed my url <snip> to example in my last post.

[edited by: jdMorgan at 2:23 pm (utc) on Nov. 5, 2009]
[edit reason] No URLs, e-mails, or IM names allowed, See Terms of Service. [/edit]

If you wish to discuss a code snippet, please post it here after removing or obscuring all "personally-identifiable" information; For many reasons benefiting you as well as other members, we don't allow outgoing links to member sites, e-mail addresses, IM usernames, etc., and all such will be replaced with 'example.' Please review our Terms of Service and Apache Forum Charter for more information.

Also, please follow-up and comment on the suggestions made above, as we cannot modify or test your server for you -- this is up to you to do.

Jim

Sorry got a bit carried away!

Okay. Here is my .htaccess file(I have obscured the site with 'example.com'):

RewriteEngine On
RewriteBase /example.com
Options -MultiViews

php_value output_handler ob_gzhandler

AddType application/x-httpd-php .html .htm

My server is Unix running Apace with the following settings:

WebDav active
Fast CGI active
SSL Support active
PHP Module active

Quite simply if I use '
AddType application/x-httpd-php .html .htm' in the .htaccess I get odd results if I call any page url and end it with a / Instead I should get an error 404 which I do get if I remove the line from the .htaccess file.

Thanks

Are you using AcceptPathInfo on an Apache 2.x server?

If so, you may need to explicitly detect requested URLs ending with a slash which do not resolve to physically-existing directories, and force a 404 response. This because otherwise, the request will (likely) be passed to your DirectoryIndex-defined 'home page' with the "/" moved to PathInfo.

You've got two mod_rewrite set-up directives, but no RewriteRules. You can delete those two lines unless you decide to add a rule to fix this problem rather than turning off AcceptPathInfo.

Jim

Option 3 (I think) is remove the trailing / from locations requested with a . in the URL whether you turn AcceptPathInfo off or not...

RewriteCond %{REQUEST_URI} ^([^.]+)\.htm/$
RewriteRule /$ http://www.example.com/%1.htm [R=301,L]

The above rule checks only to see if the URL ends in a / and if it does, then the condition stores 'anything not a dot' for back-reference (by using () around the pattern to match) and checks to see if there is a . (dot) in the REQUEST_URI followed by htm/ ... If the URL does not end in a / nothing happens. If the REQUEST_URI does not end in .htm/ nothing happens. If the REQUEST_URI does end in .htm/, people are redirected to the correct location using the information stored for back-reference in the condition by referencing it with %1.

Personally, as a visitor I'd get a bit grouchy if I clicked on a link to /mypage.htm/ and got a 404, when the site owner could easily strip the / from the end of the URL for me, rather than making me delete it myself to see the page, and as I site owner I would want credit for the inbound link. IOW I would probably opt for the redirect regardless of the AcceptPathInfo setting...

If that's the option that's needed, the rule can also be simplified to a one-liner:

RewriteRule ^([^.]+\.+htm)/$ http://www.example.com/$1 [R=301,L] 

Jim

You CSS blows up if you have a relative link to the file, not an absolute path beginning with / or a fll URL including domain name. Change the link to either of those formats to get it working.

If that's the option that's needed, the rule can also be simplified to a one-liner:

RewriteRule ^([^.]+\.+htm)/$ http://www.example.com/$1 [R=301,L]

I thought of that one too, but only wanted to compare a anything if there was a / at the end, IOW I didn't want to match every \.htm request without a / at the end, because it seems to me it's much more likely to have the correct (no trailing /) location selected, so I wanted to avoid matching those if possible. Maybe I don't gain anything by not start-anchoring the rule and just comparing the last character to see if it's a / and then checking everything if it could match .htm/ at the end?

It seems with yours (and I seriously considered suggesting something *very* similar to what you did, but opted for a condition after thinking about it for a while) would match anything requested up to a . or any .htm request up to the /, even if correctly requested without a trainling / and that's what I was trying to avoid...

If anyone has thoughts on my reasoning for writing the rule with a condition the way I did I'd be happy to hear them. Thanks!

Wow! Fantastic response to my problem.
I have used TheMadScientis's

RewriteCond %{REQUEST_URI} ^([^.]+)\.htm/$
RewriteRule /$ http://www.example.com/%1.htm [R=301,L]

and it works.

I will make further tests to see if this doesn't throw up any other problems...but it's looking good.

Big thanks.

In .htaccess, shorter code is almost always better, so there's no reason to add another directive (the RewriteCond) if an unambiguous "decision" can be made using just the RewriteRule.

I haven't benchmarked this case to be able to give an authoritative answer, but while it's possible that the two-line solution might be faster in a server-config-file context where the code is "pre-compiled" at server start-up, it is almost certain that the one-line solution will be "faster" in a per-directory context, where the code is re-compiled for each and every HTTP request. So even if the rule isn't executed in .htaccess for a particular HTTP request, you still have to "pay" for the added compile time of the extra line for every request.

In the end, the difference will be small, and such things may just come down to 'style' -- Either rule-set will work and accomplish the same goal... :)

Jim

I haven't benchmarked this case to be able to give an authoritative answer, but while it's possible that the two-line solution might be faster in a server-config-file context where the code is "pre-compiled" at server start-up, it is almost certain that the one-line solution will be "faster" in a per-directory context, where the code is re-compiled for each and every HTTP request. So even if the rule isn't executed in .htaccess for a particular HTTP request, you still have to "pay" for the added compile time of the extra line for every request.

Thanks for the 'and why' portion of the reasoning / logic...
I appreciate it!