Jump to content

Recommended Posts

3 minutes ago, SaranacLake said:

I know you are trying to help, but I'd sorta prefer not to do that since the log file contains sensitive info and it would be a pain to have to scrub it out.

Then I guess you're stuck figuring it out on your own.  Without new info there's really nothing else to be said.  The rules you've posted work just fine for me on Apache 2.4.  Maybe there's an issue with 2.2 causing a difference, but I'm likewise not going to go through the hassle of setting up an Apache 2.2 environment to test.

Your re-cap above has various errors in it, but I'm assuming they are just typos trying to transfer data to the post and not actual problems because otherwise Apache wouldn't start and you'd have no output.

7 minutes ago, kicken said:

Then I guess you're stuck figuring it out on your own.  Without new info there's really nothing else to be said.  The rules you've posted work just fine for me on Apache 2.4.  Maybe there's an issue with 2.2 causing a difference, but I'm likewise not going to go through the hassle of setting up an Apache 2.2 environment to test.

Your re-cap above has various errors in it, but I'm assuming they are just typos trying to transfer data to the post and not actual problems because otherwise Apache wouldn't start and you'd have no output.

I fixed some type-o's?

Should I try updating to a newer version of MAMP with Apache 2.4 if that is offered?

So you want me to access the page using cURL and past a clean log here?

 

Edited by SaranacLake
Fixed known type-o's
7 minutes ago, SaranacLake said:

So you want me to access the page using cURL and past a clean log here?

That would be ideal, similar to what I did in a previous post.  The important bits of the log are from the [rid# bit til the end of the line.  There's a lot of info before that which can be removed.

 

 

4 minutes ago, kicken said:

That would be ideal, similar to what I did in a previous post.  The important bits of the log are from the [rid# bit til the end of the line.  There's a lot of info before that which can be removed.

 

Working on it...

@kicken

Here you go...

	This log file was created after running...
	    curl -i http://local.mydomain/client1/gallery/2019-holiday-party
	
************************
127.0.0.1 - - [04/Dec/2019:20:38:13 --0800] [local.mydomain/sid#7f80a305c320][rid#7f80a30b3aa0/initial] (3) [perdir /Users/user1/Documents/60-MYDOMAIN/10-INFORMATION_TECHNOLOGY/++htdocs/05-MyDomain/public_html/] strip per-dir prefix: /Users/user1/Documents/60-MYDOMAIN/10-INFORMATION_TECHNOLOGY/++htdocs/05-MyDomain/public_html/client1/gallery/2019-holiday-party -> client1/gallery/2019-holiday-party
	127.0.0.1 - - [04/Dec/2019:20:38:13 --0800] [local.mydomain/sid#7f80a305c320][rid#7f80a30b3aa0/initial] (3) [perdir /Users/user1/Documents/60-MYDOMAIN/10-INFORMATION_TECHNOLOGY/++htdocs/05-MyDomain/public_html/] applying pattern '^(.*)index.php$' to uri 'client1/gallery/2019-holiday-party'
	127.0.0.1 - - [04/Dec/2019:20:38:13 --0800] [local.mydomain/sid#7f80a305c320][rid#7f80a30b3aa0/initial] (3) [perdir /Users/user1/Documents/60-MYDOMAIN/10-INFORMATION_TECHNOLOGY/++htdocs/05-MyDomain/public_html/] strip per-dir prefix: /Users/user1/Documents/60-MYDOMAIN/10-INFORMATION_TECHNOLOGY/++htdocs/05-MyDomain/public_html/client1/gallery/2019-holiday-party -> client1/gallery/2019-holiday-party
	127.0.0.1 - - [04/Dec/2019:20:38:13 --0800] [local.mydomain/sid#7f80a305c320][rid#7f80a30b3aa0/initial] (3) [perdir /Users/user1/Documents/60-MYDOMAIN/10-INFORMATION_TECHNOLOGY/++htdocs/05-MyDomain/public_html/] applying pattern '.*' to uri 'client1/gallery/2019-holiday-party'
	127.0.0.1 - - [04/Dec/2019:20:38:13 --0800] [local.mydomain/sid#7f80a305c320][rid#7f80a30b3aa0/initial] (4) [perdir /Users/user1/Documents/60-MYDOMAIN/10-INFORMATION_TECHNOLOGY/++htdocs/05-MyDomain/public_html/] RewriteCond: input='/Users/user1/Documents/60-MYDOMAIN/10-INFORMATION_TECHNOLOGY/++htdocs/05-MyDomain/public_html/client1/gallery/2019-holiday-party' pattern='!-d' => not-matched
	127.0.0.1 - - [04/Dec/2019:20:38:13 --0800] [local.mydomain/sid#7f80a305c320][rid#7f80a30b3aa0/initial] (3) [perdir /Users/user1/Documents/60-MYDOMAIN/10-INFORMATION_TECHNOLOGY/++htdocs/05-MyDomain/public_html/] strip per-dir prefix: /Users/user1/Documents/60-MYDOMAIN/10-INFORMATION_TECHNOLOGY/++htdocs/05-MyDomain/public_html/client1/gallery/2019-holiday-party -> client1/gallery/2019-holiday-party
	127.0.0.1 - - [04/Dec/2019:20:38:13 --0800] [local.mydomain/sid#7f80a305c320][rid#7f80a30b3aa0/initial] (3) [perdir /Users/user1/Documents/60-MYDOMAIN/10-INFORMATION_TECHNOLOGY/++htdocs/05-MyDomain/public_html/] applying pattern 'client1/gallery/(.*)$' to uri 'client1/gallery/2019-holiday-party'
	127.0.0.1 - - [04/Dec/2019:20:38:13 --0800] [local.mydomain/sid#7f80a305c320][rid#7f80a30b3aa0/initial] (4) [perdir /Users/user1/Documents/60-MYDOMAIN/10-INFORMATION_TECHNOLOGY/++htdocs/05-MyDomain/public_html/] RewriteCond: input='/Users/user1/Documents/60-MYDOMAIN/10-INFORMATION_TECHNOLOGY/++htdocs/05-MyDomain/public_html/client1/gallery/2019-holiday-party' pattern='!-f' => matched
	127.0.0.1 - - [04/Dec/2019:20:38:13 --0800] [local.mydomain/sid#7f80a305c320][rid#7f80a30b3aa0/initial] (2) [perdir /Users/user1/Documents/60-MYDOMAIN/10-INFORMATION_TECHNOLOGY/++htdocs/05-MyDomain/public_html/] rewrite 'client1/gallery/2019-holiday-party' -> 'client1/gallery/photo-gallery.php?gallery-id=2019-holiday-party'
	127.0.0.1 - - [04/Dec/2019:20:38:13 --0800] [local.mydomain/sid#7f80a305c320][rid#7f80a30b3aa0/initial] (3) split uri=client1/gallery/photo-gallery.php?gallery-id=2019-holiday-party -> uri=client1/gallery/photo-gallery.php, args=gallery-id=2019-holiday-party
	127.0.0.1 - - [04/Dec/2019:20:38:13 --0800] [local.mydomain/sid#7f80a305c320][rid#7f80a30b3aa0/initial] (3) [perdir /Users/user1/Documents/60-MYDOMAIN/10-INFORMATION_TECHNOLOGY/++htdocs/05-MyDomain/public_html/] add per-dir prefix: client1/gallery/photo-gallery.php -> /Users/user1/Documents/60-MYDOMAIN/10-INFORMATION_TECHNOLOGY/++htdocs/05-MyDomain/public_html/client1/gallery/photo-gallery.php
	127.0.0.1 - - [04/Dec/2019:20:38:13 --0800] [local.mydomain/sid#7f80a305c320][rid#7f80a30b3aa0/initial] (2) [perdir /Users/user1/Documents/60-MYDOMAIN/10-INFORMATION_TECHNOLOGY/++htdocs/05-MyDomain/public_html/] trying to replace prefix /Users/user1/Documents/60-MYDOMAIN/10-INFORMATION_TECHNOLOGY/++htdocs/05-MyDomain/public_html/ with /
	127.0.0.1 - - [04/Dec/2019:20:38:13 --0800] [local.mydomain/sid#7f80a305c320][rid#7f80a30b3aa0/initial] (4) add subst prefix: client1/gallery/photo-gallery.php -> /client1/gallery/photo-gallery.php
	127.0.0.1 - - [04/Dec/2019:20:38:13 --0800] [local.mydomain/sid#7f80a305c320][rid#7f80a30b3aa0/initial] (1) [perdir /Users/user1/Documents/60-MYDOMAIN/10-INFORMATION_TECHNOLOGY/++htdocs/05-MyDomain/public_html/] internal redirect with /client1/gallery/photo-gallery.php [INTERNAL REDIRECT]
	

2 hours ago, SaranacLake said:

RewriteCond: input='/Users/user1/Documents/60-MYDOMAIN/10-INFORMATION_TECHNOLOGY/++htdocs/05-MyDomain/public_html/client1/gallery/2019-holiday-party' pattern='!-d' => not-matched

This tells me you have an actual directory named 2019-holiday-party inside your gallery folder.  When I created a similar directory on my end then I get results similar to yours.

The problem is mod_dir which in addition to handling DirectoryIndex files,

Quote

A "trailing slash" redirect is issued when the server receives a request for a URL http://servername/foo/dirname where dirname is a directory. Directories require a trailing slash, so mod_dir issues a redirect to http://servername/foo/dirname/.

I'm not sure exactly how it's interacting with your mod_rewrite rules, but it appears as though it's triggers based on the original request url instead of the re-written URL.  When it issues the redirect however it still picks up the query-string that was added to the re-written URL.

This trailing slash behavior can be disabled by setting DirectorySlash Off in your configuration.  That should resolve the problem, though I'm not sure it's a good solution.  Another solution would be to make sure your pretty URL's don't map to an actual directory on the server.

 

  • Thanks 1

F*** ME!!!!

I KNEW that the answer would be something stupid!!

@kicken,

You are indeed a "Guru" - and a gentleman - among men!!

 

10 hours ago, kicken said:

This tells me you have an actual directory named 2019-holiday-party inside your gallery folder.

Right.  I have this structure...

	public_html
	     index.php
	     client1/
	          menu.php
	          gallery/
	               photo-gallery.php
	               2019-holiday-party/
	                    img_0001.jpg
	                    img_0002.jpg
	                    img_0003.jpg
	               2019-diwali-festival/
	                    img_0004.jpg
	                    img_0005.jpg
	               2019-company-picnic/
	                    img_0006.jpg
	

 

The logic being that when you are on menu.php, you click on the link of the gallery you want to view, and that is a "pretty" URL like this...  "client1/gallery/2019-holiday-party" 

That in turn launches /public_html/client1/gallery/photo-gallery.php which grabs the $_GET['gallery-id'] from the "pretty" URL

And then this script finds a directory by that SAME NAME, and then it reads all of the photos in said directory, and displays them on the photo-gallery.php page!!

 

Quote

When I created a similar directory on my end then I get results similar to yours.

The problem is mod_dir which in addition to handling DirectoryIndex files,

I'm not sure exactly how it's interacting with your mod_rewrite rules, but it appears as though it triggers based on the original request url instead of the re-written URL.  When it issues the redirect however it still picks up the query-string that was added to the re-written URL.

 

So, as a test, I pre-pended my photo directories with X_ and then tweaked my photo-gallery.php code like this...

	$photoPath = "../gallery/X_$galleryID/";
	

 

When I do that, miraculously everything works, including a *proper* pretty URL and all of the photos from that directory being served up.

But having to hack things like that is annoying at best...

 

Quote

This trailing slash behavior can be disabled by setting DirectorySlash Off in your configuration.  That should resolve the problem, though I'm not sure it's a good solution. 

 

What I am trying to do here has to be extremely common from a programming standpoint?!

Can you, or anyone else, think of a way to "have my cake and eat it too"?

Like you, I am a little leery about setting DirectorySlash Off because I fear it could break the code for my separate e-commerce site which is very complex and nearing completion.

 

Cannot believe that I just pissed away 4 days on this damn photo-gallery for work website.  What a waste of time, but THANK YOU (and @requinix ) for teaching me new things.

If you can think of a way to have directories with the same names as my pretty URL that would be ideal...

Thanks again!!    :thumb-up::thumb-up:

 

 

 

Edited by SaranacLake

P.S.  Apache stuff is my weak point - thus why I am here for help!  But I have been trying to find an answer for my above desired outcome.

Are any of these links viable solutions?

https://stackoverflow.com/uestions/21417263/htaccess-add-remove-trailing-slash-from-url

https://serverfault.com/questions/607207/directiryindex-not-working-properly-for-rewritten-url

 

31 minutes ago, SaranacLake said:

If you can think of a way to have directories with the same names as my pretty URL that would be ideal

One option might be to ignore mod_rewrite and instead use DirectoryIndex.  Most people only use this to set an index file name for directories, but you can actually set it to a specific URL which will handle requests for directories.  That script can then grab the URL requested and handle it as needed.

/client1/gallery/.htaccess

DirectoryIndex /client1/gallery/photo-gallery.php

photo-gallery.php

<?php
    if (!preg_match('#/client1/gallery/(.*)/$#', $_SERVER['REQUEST_URI'], $matches)){
        die('Invalid request');
    } else {
        $gallery = $matches[1];
    }
?>
<!DOCTYPE html>
<body>
    <p>Browsing <?=$gallery?></p>
</body>

 

 

6 minutes ago, kicken said:

One option might be to ignore mod_rewrite and instead use DirectoryIndex.  Most people only use this to set an index file name for directories, but you can actually set it to a specific URL which will handle requests for directories.  That script can then grab the URL requested and handle it as needed.

 

I could, but that just seems unnatural to me.

What about the link above?

https://stackoverflow.com/questions/21417263/htaccess-add-remove-trailing-slash-from-url

Right below the RewriteEngine On line, add:

To enforce a no-trailing-slash policy.

	RewriteCond %{REQUEST_FILENAME} !-d RewriteRule ^(.*)/$ /$1 [L,R] # <- for test, for prod use [L,R=301]
	

 

To enforce a trailing-slash policy:

	RewriteCond %{REQUEST_FILENAME} !-f RewriteRule ^(.*[^/])$ /$1/ [L,R] # <- for test, for prod use [L,R=301]
	

 

[EDIT: commented the R=301 parts because, as explained in a comment:

Be careful with that R=301! Having it there makes many browsers cache the .htaccess-file indefinitely: It somehow becomes irreversible if you can't clear the browser-cache on all machines that opened it. When testing, better go with simple R or R=302

After you've completed your tests, you can use R=301.

 

That sounds like it has promise, although I'm not sure where to put the first block of code in my current .htaccess file with mod_rewrites??  :shrug:

You can't really use any kind of Rewriting to solve the issue as far as I could see.   I tried doing a little searching last night before posting for potential solutions but couldn't find anything.  Because your friendly URL maps to a valid directory mod_dir is going to want to redirect in order to add that trailing slash unless you disable it with DirectorySlash Off.

Personally, I'd go with the DirectoryIndex solution I mentioned above, I think it's the best overall solution if you want to keep your current folder structure. It means your URL will end with a /, but that fine IMO.  Just isolate the configuration to your gallery directory by putting it in it's own .htaccess file or in a <Directory> block in your VirtualHost configuration. 

If that trailing / is really a problem for you, then my second choice solution would be to just move your gallery directories into a sub-folder or something so they don't match your pretty URLs.

2 hours ago, SaranacLake said:

What I am trying to do here has to be extremely common from a programming standpoint?!

Rewriting is common, but usually a person's pretty-url's don't match actual filesystem paths.  Either the content is in a database and not in a filesystem at all, or it's stored differently in the filesystem (such as with an extension that is added by the rewrite).  Usually if a url maps to a valid file/directory people want that file/directory to be served which is why you see a lot of RewriteCond's checking for !-d and !-f.

Your problem is due to the specific condition of having your desired pretty URL's match your filesystem which is causing a conflict between what mod_dir wants to do and what mod_rewrite wants to do.  There's a handful of cases of this issue I saw searching google, but not very many.  Maybe there's a solution that will resolve the conflict while keeping your structure, but I couldn't find it and don't feel much like continuing the search when there are simple alternatives.

13 minutes ago, kicken said:

Personally, I'd go with the DirectoryIndex solution I mentioned above, I think it's the best overall solution if you want to keep your current folder structure. It means your URL will end with a /, but that fine IMO.  Just isolate the configuration to your gallery directory by putting it in it's own .htaccess file or in a <Directory> block in your VirtualHost configuration. 

I trust that it works, it just looked Greek to me and since this is a favor website for my co-workers, I'm trying to not spend forever on it.

 

13 minutes ago, kicken said:

If that trailing / is really a problem for you, then my second choice solution would be to just move your gallery directories into a sub-folder or something so they don't match your pretty URLs.

Or prepend it with X_ which works...

 

13 minutes ago, kicken said:

Rewriting is common, but usually a person's pretty-url's don't match actual filesystem paths.  Either the content is in a database and not in a filesystem at all, or it's stored differently in the filesystem (such as with an extension that is added by the rewrite).  Usually if a url maps to a valid file/directory people want that file/directory to be served which is why you see a lot of RewriteCond's checking for !-d and !-f.

True

 

13 minutes ago, kicken said:

Your problem is due to the specific condition of having your desired pretty URL's match your filesystem which is causing a conflict between what mod_dir wants to do and what mod_rewrite wants to do.  There's a handful of cases of this issue I saw searching google, but not very many.  Maybe there's a solution that will resolve the conflict while keeping your structure, but I couldn't find it and don't feel much like continuing the search when there are simple alternatives.

 

What I thought was maybe I could tell Apache, "If you come across "client1/gallery/(.*)"  (e.g. "/client1/gallery/2019-holiday-party") then do NOT treat it the normal way like a directory, but instead make an exception and treat (.*) like is a file.

That seems doable, although I'm not experienced enough with mod_rewrites to do that for fear of blowing things up.

Thoughts?

 

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.