Today we are receiving a most odd error box while creating new redirects. It is as follows:

"An HTTP error 0 occurred http://domain.org/js/path_redirect/autocomplete_404"

At the point it pops up, we have already pasted in the destination URL and are trying to enter a redirect name.

In the watchdog table, we are seeing 404's at this same time with really strange paths something is attempting to access, such as:

Location http://domain.org/js/path_redirect/autocomplete_404/Gift
Referrer
Message js/path_redirect/autocomplete_404/Gift

Which "GiftMembership" was the redirect we were trying to create.

Why in the world would the code go off and try to ask Apache part of the redirect name we are trying to create before we even get done filling in the form!?

Comments

pnigro’s picture

pnigro commented

I am experiencing the same thing. If I right click and paste the path in the autocomplete field I do not receive the error. However, if I press "ctrl + v" (keyboard equivalent for paste) I do receive the error.

jmventura’s picture

jmventura commented

Check you are not prefixing the address with a slash while creating the alias, "/path_to_my_redirect" must be "path_to_my_redirect".

mdlueck’s picture

mdlueck commented

@jmventura #2: I brought one of our existing / working URL Redirects into edit mode, verified that the "From:" had no slash, Backspace to eat up a couple of characters of the end of the value, and up popped the dreaded box.

Location	http://domain.org/js/path_redirect/autocomplete_404/GiftMembersh
Referrer	
Message	js/path_redirect/autocomplete_404/GiftMembersh
jmventura’s picture

jmventura commented

You also need to wait the blue throbber at the end of the text filed to stop spinning before saving the changes, it's the same kind of weird behavior that views has, some kind of AJAX validation.

crifi’s picture

crifi commented

This problem is maybe caused by a wrong configuration of $base_url and should be prevented by inserting a warning message to the requirements system. Therefore I created a new issue #1046682: Install/Update process fails if $base_url is set to a wrong URL. Please close this bug as a duplicate, if this solves your issue. Thanks!

mdlueck’s picture

mdlueck commented

I assume that issue #1046682 is talking about having the $base_url set to the www. or non-www. and .htaccess rules flipping it to the other one. That is not the case in our installation.

However the protocol is different. We have https:// enabled on this site, so the /admin area is all https://. The $base_url is set to http://. Is that enough of a difference to cause the error?

crifi’s picture

crifi commented

The issue in #1046682: Install/Update process fails if $base_url is set to a wrong URL also occurs if you point your $base_url to a "http://" site, but your virtual host config only allows access over "https://", so that the $base_url is not reachable and a HTTP Error (for example 301) is returned. In this case the AJAX request couldn't be completed. Your error report assume to me, that your $base_url is not reachable (Error 404).

mdlueck’s picture

mdlueck commented

In our case, the http:// version is definitely reachable. We have the SecurePages mod installed to secure only specific nodes or collections of nodes. Nothing in .htaccess is messing with http:// vs https://.

Just to be sure I removed admin* from the Secure Pages settings and that prevents this popup from happening.

@jmventura #4: Yes I do now see the spinning clock sort of icon at the end of the "From" field. It has animation each time I backspace nibble a character.

So, @crifi what is the solution to have both SecurePages with "admin*" in its configuration list and your mod happy at the same time?

crifi’s picture

crifi commented

I assume that SecurePages is redirecting AJAX request (HTTP Code 30x) of URL parts admin* to the https:// version which is definitely not part of your $base_url, so the AJAX request couldn't be completed. Maybe this is already the problem, because www/non-www rewrite-rules are also answering with 301 and redirect to other URLs and caused my issue...

butterfi’s picture

butterfi commented

Having the same issue here. In our case we don't have $base_url set at all.

Similar to comment one, if I paste the URL in the "From" box and move on before the ajax kicks in, it works fine. Maybe can we get a "don't use ajax lookups option?" We have hundreds of redirects, so I can see this getting slower as time goes on.

mdlueck’s picture

mdlueck commented

@butterfi #10, do you have the SecurePages mod installed with "admin*" in its configuration?

hefox’s picture

hefox commented

Got this in 7 stable when pasted an external url (edited it to internal in textfield) into from.

Almost exact error message: https://skitch.com/hefoxed/rtbm4/1f186a5acee10c4f405a3253e5ff3477.png-pn...

wiredescape’s picture

wiredescape commented

Same error.
Using base_url set to http & secure_pages with admin*
If I remove admin* error goes away.
Same with both rc1 & rc2

fizk’s picture

fizk commented

Affecting me too.

wiredescape’s picture

wiredescape commented

In my case ajax errors were caused by securepages module.

For solution see http://drupal.org/node/863562 for simple patch.

mdlueck’s picture

mdlueck commented

@WiredEscape #15: I have applied the 863562 patch to v1.9 of the mod. (I tested applying it to v1.8 code and the patch applies the same to both.)

I still get a 50% popup box, in fact in testing I just did with this Path Redirect mod, backspacing characters from a pre-existing Path Redirect, it was every other time that it would do the lookup successfully / pop the dialog / do the lookup / pop the dialog.

So not a 100% fix, but progress.

And yes, the dialog text did change over to HTTPS vs the original HTTP. So I know the patch to Secure Pages is in effect.

butterfi’s picture

butterfi commented

This issue went away for me, and I strongly suspect that updating Chaos Tools is what fixed it for me, but I'm not positive. YMMV.

mdlueck’s picture

mdlueck commented

#butterfi #17: I have never heard of "Chaos Tools" so that mod is definitely not in the mix in our environment.

acrollet’s picture

acrollet commented
Version: 6.x-1.0-rc2 » 6.x-1.x-dev

FYI: I was able to work around this issue by adding the line

js/path_redirect/*

to the 'ignore' list in securepage's configuration.

best,

Adrian

mdlueck’s picture

mdlueck commented

@Adrian #19

Thanks for finding that work-around! Indeed that works for us as well.

shotokai’s picture

shotokai commented

#19 Works for us, as the issue was with secure pages. In this case this isn't a bug, but misconfiguration of the secure pages module.

bkosborne’s picture

bkosborne
Primary language English
Location New Jersey, USA
commented

If you have secure pages enabled have admin/* on HTTPS, then you have to do #19. That will tell secure pages to ignore it.

This is the case for nearly all AJAX requests that are made from HTTPS with secure pages enabled.

mustafa.ata’s picture

mustafa.ata commented

Thanks Acrollet, it worked for me.

aidanlis’s picture

aidanlis commented

If you're using the high performance JS framework you'll also get an error, http://drupal.org/project/js

I wasn't able to get path_redirect to use the JS framework (because it uses an include, which can be fixed, but then path_redirect_init was still being fired and I ran out of time).

The simplest solution was adding this:

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} ^\/js\/.*
+ RewriteCond %{REQUEST_URI} !^\/js\/path_redirect\/.*
RewriteRule ^(.*)$ js.php?q=$1 [L,QSA]