Hi,

I have pretty URLs enabled with CouchCMS, and working correctly, using the code generated by the gen_htaccess script.

I've set up a custom 404.php file for my site, which is working fine when I load it directly (i.e. /404.php), and also when I try to access a known non-existent file with a php extension (e.g. /frog.php).

However, when I type in a known non-existent file with a .html or / extension (e.g. /frog.html or /frog/ ), I get a '401 - authorisation required' message instead of my 404 page. (This also happens if I am not using a custom 404 page.)

My couch subdirectory is htaccess password protected, but the issue persists even when I switch this off.

My theory is that Couch is trying to rewrite these urls using the htaccess rules, and is somehow missing the fact that it's not a valid file (or folder), and so is trying to display a URL for a page/folder that doesn't exist, which is somehow not being caught as a 404.

#index.php
RewriteRule ^.*?([^\.\/]*)\.html$ ?pname=$1 [L,QSA]
RewriteRule ^([1-2]\d{3})/(?:(0[1-9]|1[0-2])/(?:(0[1-9]|1[0-9]|2[0-9]|3[0-1])/)?)?$ ?d=$1$2$3 [L,QSA]
RewriteRule ^[^\.]*?([^/\.]*)/$ ?fname=$1 [L,QSA]
RewriteRule ^\w[^\.]*?([^/\.]*)$ "$0/" [R=301,L,QSA]

Are the htaccess rules creating this problem?

Is there a solution for this?

Do you have any suggestions for things that I can try?

Do you need any more information to better understand the behaviour I'm seeing?

Thank you,

Nikki

[KK]

Hello and welcome, Nikki,

'401 - authorisation required' error is commonly encountered with directories password protected using 'HTTP Basic Authentication', which is how, as you stated, the 'couch' subdirectory is protected on your setup.

The 404.php file is in the site's root (and not in 'couch') so really should not be affected by that arrangement but it does raise suspicion.

Would it be possible for you to grant me temporary FTP/Couch access to your setup? I'd like to see first-hand what the problem could be.

Thanks.

Hi KK,

Thanks, that was what I needed to know. I took away all htaccess password protections and it started working perfectly.

So then I started adding them back (I had two), and found that it was NOT the one in the couch directory that was causing the problem.

It was a second one I had at the webroot, and my development site was in a subdirectory of that webroot.

In other words I had my site at this location
http://my.developmentdomain.com/test-site-3/
(plus previous versions of the site at
http://my.developmentdomain.com/test-site-1/
http://my.developmentdomain.com/test-site-2/
etc)

and an htaccess file in the webroot of
http://my.developmentdomain.com/

to stop access to the my development space by anyone but myself and the client, as I created the new version of the site.

As soon as I remove the htaccess password protection from
http://my.developmentdomain.com/
the 404 page loads correctly for /frog.php, /frog.html and /frog/

Thank you

And thanks for creating this awesome piece of software. I've been incredibly impressed with its power, thorough documentation and deceptive simplicity. I've had a ball learning how to use it (I love the tutorial) and I expect to use it many more times again.

Cheers,

Nikki

OK, almost perfectly.

I migrated my dev site to a new empty webroot, to test the migration process (which worked well, thank you).

However, my '403 - Access Forbidden' errors have returned.

In this case, there is no htaccess file in the webroot (and the site is now directly in the webroot), and only one in the couch directory.

Through trial and error I have discovered that by commenting out this line in my root htaccess file, from the index.php 'pretty url' rules section:
RewriteRule ^.*?([^\.\/]*)\.html$ ?pname=$1 [L,QSA]
that '/frog.html' will correctly show my 404 page.

Similarly, when I comment out these two lines, in the index.php 'pretty url' rules section:
RewriteRule ^[^\.]*?([^/\.]*)/$ ?fname=$1 [L,QSA]
RewriteRule ^\w[^\.]*?([^/\.]*)$ "$0/" [R=301,L,QSA]
'/frog/' correctly shows my 404 page.

I don't have the skills read the htaccess rewrite rules syntax down to the last detail, but it looks to me like the first rule assumes that any .html file not listed in the previous rules should be rewritten with the ?pname= extension, as if it trying to serve a page that doesn't exist without checking whether it exists first, somehow bypassing the 404 check?

And the same for any URL ending in a / - it's assuming that it is a folder, but one that does not actually exist.

I want to make sure that if someone mistypes a URL accidentally, that it will redirect them correctly to my 404 page, but these rules seem to be playing funny with that.

I removed my htaccess file from the couch subdirectory entirely, and this made no difference to the behaviour, so I don't believe it has anything to do with the problem that I'm seeing.

Can you shed any light on what's going on here?

It might be possible for me to grant you temporary FTP/Couch access to my site, but I'll have to ask my server admin to help me with that. I'm not sure if it can be accessed externally.

Any ideas you have in the meantime, and your thoughts on those rewrite rules, would be really appreciated.

Thank you,

Nikki

[KK]

my '403 - Access Forbidden' errors have returned.

Not quite. The error you reported previously was '401 - authorisation required'.
The two errors are different and have different causes.

I think I know what might be going wrong (and it is not the rewrite rules).
Could you please let me know two things?
1. Can you access the 404.php file directly by typing its URL in the browser?
2. Which version of Couch are you using? (1.3.5 or the latest 1.4)

Please let me know.
Thanks.

Ha ha, you're right. It must have been late at night, and I completely missed that the errors were different. Sorry about that.

1. Yes I can access the file by typing it directly.
2. And I'm using 1.3.5.

Thanks,

Nikki

[KK]

Nikki,

I'd PMed you a patch yesterday.
Perhaps you did not get a notification.
Please check your messages.

Do let me know if the patch works.

Thanks.

Hi,

It turned out that the problem was because I was in a testing environment, and not on the actual live domain, which already had an existing old (non-Couch) site in place.

I set up the new test site as if it was using the new domain, so I could test as many features as fully as possible before transferring it to the live site, and edited my hosts file in order to be able to view and edit pages.

But with KK's help, we determined that not all calls were internal, and so the new development server was making calls to the old website (by using the actual domain for the old live website) for resources that only existed on the new development site.

Once I deployed the new CouchCMS site on the live server and domain, the redirects started working correctly.

Problem solved!

Thanks,

Nikki