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.
Comment | File | Size | Author |
---|---|---|---|
#3 | htaccess-1962780-3.patch | 671 bytes | David_Rothstein |
Comments
Comment #1
BerdirPlease provide a patch for the change.
Comment #2
BerdirAlso, http://drupal.org/requirements/webserver says that Drupal 7 "likely" works on Apache 1.3, not sure about this being a critical :)
Comment #3
David_Rothstein CreditAttribution: David_Rothstein commentedThis 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...
Comment #4
David_Rothstein CreditAttribution: David_Rothstein commentedComment #5
susan5in7 CreditAttribution: susan5in7 commented#3: htaccess-1962780-3.patch queued for re-testing.
Comment #6
xmacinfoNot sure if Drupal 8 should support Apache 1.3. Apache 1.x is like PHP 4.x, old and unsupported.
Comment #7
webchickYeah, I'd be more comfortable fixing this in D7 only.
Comment #8
webchickMmm. 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.
Comment #9
liza CreditAttribution: liza commentedJesus 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:
this is the kind of error am getting in the access log:
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.
Comment #10
webchickHm. 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
Comment #11
liza CreditAttribution: liza commentednope. not working.. *sigh*
will submit as a separate issue.
Comment #12
garbo CreditAttribution: garbo commentedI 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.
Comment #13
webchickAwesome, thanks garbo! That sounds like an RTBC. I'll leave it there for a couple of hours.
Comment #14
webchickAwesome!
Since this is David Rothstein's patch, committed and pushed to both 7.x and 8.x. Thanks!
Comment #15
liza CreditAttribution: liza commentedjust 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*
Comment #16
webchickHa, 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?
Comment #17
David_Rothstein CreditAttribution: David_Rothstein commentedI'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.
Comment #18
brayo4 CreditAttribution: brayo4 commentedi'm getting this same error running on Server version: Apache/2.2.24 (Unix). perplexed !!!
Comment #19
David_Rothstein CreditAttribution: David_Rothstein commented@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?
Comment #20
brayo4 CreditAttribution: brayo4 commentedYes, it appeared after 7.22 upgrade. i am using midphase if that helps..............
Comment #21
webchickbrayo4, 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.
Comment #22
brayo4 CreditAttribution: brayo4 commentedyes, 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.
Comment #23
Jooblay.net CreditAttribution: Jooblay.net commentedOn 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...
Comment #24
brayo4 CreditAttribution: brayo4 commentedi'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.
Comment #25
Jooblay.net CreditAttribution: Jooblay.net commentedI 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...
Comment #27
jorisx CreditAttribution: jorisx commentedWow. 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 :)
Comment #28
Jooblay.net CreditAttribution: Jooblay.net commented@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.
Comment #29
David_Rothstein CreditAttribution: David_Rothstein commentedThe 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.
Comment #30
Jooblay.net CreditAttribution: Jooblay.net commentedSorry 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:)
Comment #31
pslcbs CreditAttribution: pslcbs commentedPatch 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!!