Hi I want to report bug in the regexp in the file:
.htaccess

Which producing 500 Internal server error after update to the Drupal core 7.22
on the Apache 1.x (which still don't use PCRE library for regexp analysing).

If I'm understanding situation correctly D7.22 release has bug in the FilesMatch regexp pattern:
In the .htaccess is this:

<FilesMatch "\.(engine|inc|info|install|make|module|profile|test|po|sh|.*sql|theme|tpl(\.php)?|xtmpl)(|~|\.sw[op]|\.bak|\.orig|\.save)?$|^(\..*|Entries.*|Repository|Root|Tag|Template)$|^#.*#$|\.php(~|\.sw[op]|\.bak|\.orig\.save)$">

but it's wrong regex, because there must be that:

<FilesMatch "\.(engine|inc|info|install|make|module|profile|test|po|sh|.*sql|theme|tpl(\.php)?|xtmpl)(~|\.sw[op]|\.bak|\.orig|\.save)?$|^(\..*|Entries.*|Repository|Root|Tag|Template)$|^#.*#$|\.php(~|\.sw[op]|\.bak|\.orig\.save)$">

because in the regex | is always binary operator.

Maybe PCRE used in the Apache 2.x is a bit benevolent, but it is error anyway and will be nice to be fixed soon.

Thanks,
Petr.

CommentFileSizeAuthor
#3 htaccess-1962780-3.patch671 bytesDavid_Rothstein
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Berdir’s picture

Please provide a patch for the change.

Berdir’s picture

Also, http://drupal.org/requirements/webserver says that Drupal 7 "likely" works on Apache 1.3, not sure about this being a critical :)

David_Rothstein’s picture

Version: 7.22 » 8.x-dev
Status: Active » Needs review
Issue tags: +Needs backport to D7
FileSize
671 bytes

This will need to go in Drupal 8 first, but the attached patch applies equally well to Drupal 7. (Credit for this patch should go to @petyovsky, not me). It looks right but I haven't really tested.

I'll mention this in the 7.22 release notes and also ping the people at #1907704: Restrict temporary files created by text editors about it. Yeah, we should fix this because in theory Drupal 7 is supposed to run on Apache 1.3, but as far as I know that version of Apache has not been supported by the Apache folks themselves for a long time...

David_Rothstein’s picture

Title: 500 Internal server error after update to the Drupal core 7.22 » 500 Internal server error on Apache 1.x servers after updating to Drupal 7.22
susan5in7’s picture

#3: htaccess-1962780-3.patch queued for re-testing.

xmacinfo’s picture

Not sure if Drupal 8 should support Apache 1.3. Apache 1.x is like PHP 4.x, old and unsupported.

webchick’s picture

Version: 8.x-dev » 7.x-dev

Yeah, I'd be more comfortable fixing this in D7 only.

webchick’s picture

Version: 7.x-dev » 8.x-dev

Mmm. Then again, from reading the OP, it sounds like this is just fixing a straight-up bug, so if it happens to make D8 work in Apache 1.x, so be it.

liza’s picture

Jesus Joseph and Mary! is this the reason why after i upgraded from 7.19 to 7.22 i can't automatically create multisites anymore?

i am actually on WAMP with Apache 2.2.22. all the paths to subdomains i have prior to the upgrade are working fine. what i can't do is summon the INSTALL.PHP for new subdomains. it just goes on forever looking for it until it hits me with this:

The connection was reset
The connection to the server was reset while the page was loading.
The site could be temporarily unavailable or too busy. Try again in a few moments.
If you are unable to load any pages, check your computer's network connection.
If your computer or network is protected by a firewall or proxy, make sure that Firefox is permitted to access the Web.

this is the kind of error am getting in the access log:

127.0.0.1 - - [09/Apr/2013:10:29:28 -0400] "GET / HTTP/1.1" 302 -

if i try forcing a new subdomain creation by dropping in a settings.php file into it's folder, i'll sometimes get a white screen. reading the page source i see the "500 INTERNAL SERVER" error and that's why i ended up here :P

please let me know if i should leave this comment here or open a new issue. i have spent the last 2 days scouring Drupal, WAMP and Apache forums trying to find a solution to this problem and have tried too many things to enumerate them here.

all i can say is that after eliminating all potential issues with my vhosts configuration, i started to search for potential issues with .htaccess. i had no idea there were changes to it until doing a compare between 7.19 and 7.22.

so, for the TL;DR: it seems changes in the .htaccess affect multisite configurations if you upgrade from 7.19 to 7.22.

webchick’s picture

Hm. Does the attached patch fix the issue? (see http://drupal.org/patch/apply) If so, that'd be great data to have so we can get it committed. If it doesn't, then a new issue might be best since this is a one-line change fixing something very specific, and it seems unlikely to affect Apache 2.x

liza’s picture

nope. not working.. *sigh*
will submit as a separate issue.

garbo’s picture

I was trying to create a fresh install from D7.22 and I was getting the error 500 too. The patch from #3 fixed the error and now I can install Drupal.

webchick’s picture

Status: Needs review » Reviewed & tested by the community

Awesome, thanks garbo! That sounds like an RTBC. I'll leave it there for a couple of hours.

webchick’s picture

Status: Reviewed & tested by the community » Fixed

Awesome!

Since this is David Rothstein's patch, committed and pushed to both 7.x and 8.x. Thanks!

liza’s picture

just wanted to pop in and say my problem was definitely NOT related to core. after days of trying to make my dev set up work again, i tore it down, rebuilt with a new install of WAMP and after bringing in every drupal installation i was working with, i found out the recursive problem was cause by a malformed profile installation i had created with the PROFILER MODULE :P i exorcised the possessed profile install and everything's been working fine... after i had torn down the whole thing in the first place *kanye/shrug*

webchick’s picture

Ha, wow. Well thanks for reporting back! Maybe upload the affected profile to the Profiler module issue queue in case there's a bug there that affects others?

David_Rothstein’s picture

Issue tags: +7.23 release notes

I'm not sure anyone above said they tested that this preserved the functionality from #1907704: Restrict temporary files created by text editors. But I just did a little testing now (with drupal.sh and various extensions added to it) and confirmed that those are still blocked.

I added this to the Drupal 7.23 CHANGELOG.txt also.

brayo4’s picture

i'm getting this same error running on Server version: Apache/2.2.24 (Unix). perplexed !!!

David_Rothstein’s picture

@brayo4, an internal server error could be caused by many different types of misconfigurations on the server. Did yours specifically appear after upgrading to Drupal 7.22?

brayo4’s picture

Yes, it appeared after 7.22 upgrade. i am using midphase if that helps..............

webchick’s picture

brayo4, if you use a -dev release of Drupal 7 instead (on your dev/test server), does the problem go away? That would have this patch applied.

brayo4’s picture

yes, ive tried new dev version as of today, still same issue. will try disabling modules.... see if i can figure out the offendor. As admin, i can access all nodes ok, just as non admin do i get the errors. tried rebuilding permissions etc...thank you for your diligent help.

Jooblay.net’s picture

On your status page,

What is your memory limit? We have received Error 500 off memory limits, often it seems drupal can suck 400MB especially in development.

We run our memory_limits at 512M almost all the time now days...

brayo4’s picture

i'm running :
max_execution_time = 180
max_input_time = 300
memory_limit = 512M

also saw this http://drupal.org/node/1561058#comment-6978088.

issue not resolved though....will keep looking for answers. thx.

Jooblay.net’s picture

I feel your search:)

Yes, just for fun if your not sure if you have a leach sucking module that you can not remember you installed. tune your memory up to something really insane:) 2056M - then test your site. You could also just use devel module to watch you mem_limits as well.

We actually found a module that sucked 1048M on page load...

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

jorisx’s picture

Wow. why is this not updated, just tried to install a clean D22 and got that nasty 500 error ... took me an hr lost time time to fix this

i just took out the first "|" in
(|~|\.sw[op]|\.bak|\.orig|\.save)?$|^(\..*|Entries.*|Repository|Root|Tag|Template)
so it is now (~|\.sw[op]|\.bak|\.orig|\.save)?$|^(\..*|Entries.*|Repository|Root|Tag|Template)

was faster then fixing it with a patch... hope that helps some

Love Drupal :)

Jooblay.net’s picture

@jorisx that is a great check...
We will run that on some tests sites. Does anyone else know why the | is in #27 @ core .htaccess ?
What is the reason for the |

This is issue is now closed... we should start a new one to talk about #27 and what the pipe | does? in the .htaccess file.

David_Rothstein’s picture

The extra | wasn't there for any purpose; that's what the bug was :) It was already removed in the patch that was committed in this issue.

Jooblay.net’s picture

Sorry wrong error 500 post we did not even look up:) must be 70 days of development on our end...
@David_Rothstein thanks for the note and your huge contribution to the community... it means more then we could ever express in words (hug) :)

We will update with the patch in #3

Power to drupal:)

pslcbs’s picture

Patch in #3 worked for me partially.

It was necessary to comment lines:

Options -Indexes
Options +FollowSymLinks

like you can read on this link http://drupal.stackexchange.com/questions/12060/what-would-cause-a-drupa...

Hope this helps somebody.

Thanks!!