suddenly getting 500 after server changeover

htaccess file suddenly ret urning a 500 code

[revrob]

My site is hosted with 1&1 in Germany and they have just done a relocation/server move. They warned of some down time but I discovered my sites were suddenly all returning a 500 code.

After examining the .htaccess files, deleting and adding back sections at a time, I discovered that remarking this section restored access to the sites.

It always worked before today, so I am presuming something in the new 1&1 hosting setup makes it no longer acceptable. Can anyone give me any clues please?

I think the code was originally to block certain types of referrer that had a malformed referrer (with a / before the domain name?) the but I can't remember the full details.

Something akin to this I think
[drupal.org...]

This is the bit of .htaccess code the new system doesn't like

***************************************
# Redirections for specific visitors
# Redirect if hostname is present in requested
# URL-path (with several variations) and matches my domain

RewriteCond $2 ^(www\.)?mydomain\.org.uk$ [NC]
RewriteRule ^/?(https?://)?([^.:/]+(\.[^.:/]+)+)\.?(:[0-9]+)?(/.*)?$ [mydomain.org.uk...] [R=301,L]
# Else return 403 if someone else's domain is in there
RewriteRule ^/?(https?://)?[^.:/]+(\.[^.:/]+)+) - [F]
*****************************************


My host gave me these notes prior to the move.
*************************************
Apart from better performance and more security, the migration to a Linux operating environment (based on Debian Squeeze/6.0) specifically adapted to the needs of 1&1 and its customers also includes the upgrade of the following components:


Apache 2.2

[apache.org...]

Please note that the migration has resulted in a number of changes in the runtime configuration. For example, the instruction 'IndexOptions FancyIndex' now takes you to the function that used to be available under the obsolete 'FancyIndex On'.

[httpd.apache.org...]

If you are using very old scripts or software, please note that after a redirect by Apache, certain internal variables, such as 'REMOTE_USER', will henceforth only be available as 'REDIRECT_REMOTE_USER'.
************************************

I've read [httpd.apache.org...]
but can't see anything obvious there - although most of it is above my head.

Many thanks in advance for any replies.
NB - I'm NOT well versed in writing Apache .htaccess files.

[lucy24]

Excuse me while I go have my jaw wired back into place.

A rewrite_rule never has the protocol and domain in the pattern; that can only go in a Condition or (if redirecting) in the target.

Throw out the existing Rule and Condition, and let's do it over again from the beginning. Start by explaining in English what you're trying to do. Or, I guess, what you used to do on the old configuration.

[g1smd]

I think they're trying to redirect a request for

http://www.example.com/http://www.example.com/somepage

to strip the double domain.

There was a long thread a few years back where jdMorgan discussed this issue is great depth. I'm not minded to go find that thread and cut and paste it here, but the OP is well advised to find it and read it in full.

[revrob]

Thanks to g1smd - I think that is the one. I had noticed various malformed requests involving referrers - invariably from scrapers that I didn't actually want - and this code was a way of serving them a 403.

I found the thread, and the code that caused lucy24's jaw to drop off, did come from jdMorgan - August last year.
[webmasterworld.com...]

I was given this:

# Redirect if hostname is present in requested URL-path (with several variations) and matches my domain
RewriteCond $2 ^(www\.)?mydomain\.com$ [NC]
RewriteRule ^/?(https?://)?([^.:/]+(\.[^.:/]+)+)\.?(:[0-9]+)?(/.*)?$ http:/ /www.mydomain.com/$5 [R=301,L]
# Else return 403 if someone else's domain is in there
RewriteRule ^/?(https?://)?[^.:/]+(\.[^.:/]+)+) - [F]

(link deliberately broken / / )

What I don't know is why it is currently causing all attempts to access my sites to return a 500 error - presumably some syntax that was okay in the old Apache setup is now not allowed in the new.
The only dfference is that my sites are .org.uk rather than .com - so I presumed that the first mention of the domain should be in the format

?mydomain\.org\.uk$5 rather than ?mydomain\.com$5

which is the only change I made to the code jdMorgan gave me

Thanks again.
Meanwhile I have put a simpler bit of code in to catch the strings containing /http and /https and give them a 403.

[lucy24]

Ouch indeed! If you don't mind, I'm going to unpack that just to make it easier for me (and anyone following along behind) to count on my fingers.

RewriteCond $2 ^(www\.)?example\.com$ [NC]
RewriteRule ^/?(https?://)?([^.:/]+(\.[^.:/]+)+)\.?(:[0-9]+)?(/.*)?$ http://www.example.com/$5 [R=301,L] 

Only captures #2 and #5 are used; the others are just grouping parentheses.

Condition: capture #2 in the rule is exactly

(www\.)?example\.com$

case-insensitive

Rule: if request is in the exact form

^/?(https?://)?

(optional slash, optionally followed by capture #1: protocol)

([^.:/]+(\.[^.:/]+)+)\.?

(capture #2, which contains capture #3: text followed by one or more sets of {full stop + more text} winding up with optional non-captured full stop)

(:[0-9]+)?

(capture #4: optional port number)

(/.*)?$

(capture #5: optional more stuff, which if present must begin with a slash)

and the Condition is met,

then redirect to

http://www.example.com/$5 [R=301,L]

(correct domain name, followed by slash, followed by capture #5 if any)

Whew. No wonder our moderator had to take sick leave ;)

[revrob]

thank you lucy24 - so do you know why it is now causing all access attempts to return a 500 code please? Is there a syntax error in what I have supplied?

I don't seem to be any nearer to solving the problem.

Update - my hosts tell me they haven't done the upgrade yet, so the mystery deepens even further as to why this started happening.