Any syntax error in httpd.conf is treated as fatal, causing httpd to refuse to startup and print an error message to help the sysop identify the error. Errors in a .htaccess file are treated as fatal to the request, causing a 500 error. This is less useful, and in some cases it may be more appropriate to ignore .htaccess syntax errors and merely log a warning. This alternative is particularly useful where a sysop wants to support users dropping in .htaccess files packaged with some-application, which might cause unnecessary errors due to conflict with AllowOverride settings, or more rarely a directive from a module that's not included. It should be possible for a sysop to configure httpd to treat errors in .htaccess as non-fatal warnings, and simply ignore (but log) the offending directives.
That can lead to security related problems (e.g. if the .htaccess contains some authentication or otherwise restrictive directives). Since we cannot know that - 500 is the safe fallback then.
That's for the server admin to determine. The current situation can also lead to security issues where AllowOverride. Posting an explanation from someone who runs hosting and is concerned about Options: - We currently disallow FollowSymLinks due to security reasons - We do allow SymLinksIfOwnerMatch which is enough for most CMS and other systems used on our platform to work - Many systems ship with .htaccess files containing "Options +FollowSymLinks" or "Options None" causing errors
I also committed a trunk patch for this in r1229021 .
Yes, I know, I was bitten by such an admin failure already (as someone who used .htaccess), hence my statement. You've just opened another vector for that. Given your explanation - I'm not sure what problem the patch is actually going to solve. The user now won't even get an error [1] and is wondering why it doesn't work. (Oh there are even docs somewhere suggesting to write garbage into the .htaccess file in order to check if the files are read at all). [1] Yes, especially in bigger hosting environments, the user doesn't have access to the error log. Well, *shrug*.
Hello Kew, We've just upgraded to 2.4.1 to test your patch. Your patch doesn't resolve issue given by you (from someone who runs hosting). I run hosting too. I've such config in users' virtualhosts: <Directory /home/someone/public_html> AllowOverride Nonfatal=All AuthConfig FileInfo Indexes Limit Options=Indexes Options -Includes -Indexes +ExecCGI +SymLinksIfOwnerMatch </Directory> And now just try to give some samples to /home/someone/public_html/.htaccess Optionz +FollowSymlinks or sth like that doesn't show any error (good, patch is working) Options +FollowSymlinks still gives me internal server error 500 So IMHO patch is useless in the situation you quoted or I use it in the wrong way.
Created attachment 30775 [details] Honour nonfatal overrides in Options set_options needs to honour the nonfatal flags - suggest something like this, which would satisfy the use case given.
Tried the patch today, confirmed it works, far better than having websites serve Internal Server Errors due to clashing options. Also, since documentation states that this IS the way the server behaves, the server should behave this way, or the documentation should be altered.
We have also been testing the patch in our environment and I can confirm it working. Is there an update on this getting merged into the stable release?
Created attachment 34093 [details] Honour nonfatal on Options All specific case
There's an edge case with the Dave's patch involving Options All and SymLinksIfOwnerMatch If you add Options All to the .htaccess and have any rewrite rule and/or symbolic links on the filesystem apache will stop serving those files and send status 500 (and remove every option already enabled in server configuration). This does look like a bug, but there is no specific documentation on how the server should behave in such situations, so the patch I've attached enables everything that is not disabled by a prior AllowOverride. P.S: Sorry for the double post, didn't notice the file was being added without any comment at all.
Comment on attachment 34093 [details] Honour nonfatal on Options All specific case --- httpd/server/core.c 2016-06-14 01:08:08.000000000 +0200 +++ httpd/server/core.c 2016-08-03 13:00:56.472620572 +0200 @@ -1971,13 +1971,38 @@ all_none = 1; } else { - return apr_pstrcat(cmd->pool, "Illegal option ", w, NULL); + if (cmd->override & NONFATAL_UNKNOWN) { + opt = 0; + ap_log_error(APLOG_MARK, APLOG_WARNING, 0, cmd->server, "Unknown Option %s in line %d of %s.", + w, cmd->directive->line_num, cmd->directive->filename); + } else { + return apr_pstrcat(cmd->pool, "Illegal option ", w, NULL); + } } if ( (cmd->override_opts & opt) != opt ) { - return apr_pstrcat(cmd->pool, "Option ", w, " not allowed here", NULL); + if (cmd->override & NONFATAL_OVERRIDE) { + ap_log_error(APLOG_MARK, APLOG_WARNING, 0, cmd->server, "Option %s not allowed in line %d of %s.", + w, cmd->directive->line_num, cmd->directive->filename); + + /* special case for Options All, we might want to enable every possible (and allowed) parameter */ + if (opt != OPT_ALL) { + first = 0; + continue; + } else { + /* + * OPT_ALL doesnt include OPT_SYM_OWNER but its important to enable that one too + * also take in mind that Options All does not have + or - so it'll be added to the already enabled options + * this means it'll enable everything that is allowed to be overriden + */ + opt = (OPT_ALL | OPT_SYM_OWNER) & cmd->override_opts; + } + } else { + return apr_pstrcat(cmd->pool, "Option ", w, " not allowed here", NULL); + } } - else if (action == '-') { + + if (action == '-') { /* we ensure the invariant (d->opts_add & d->opts_remove) == 0 */ d->opts_remove |= opt; d->opts_add &= ~opt;
Created attachment 34099 [details] Honour nonfatal unknown for options all If an option is not correct it does nothing. Also fixes a small mistake in attachment 34093 [details] which, although it was working, wasn't correct at all.
I would suggest that the real solution to the current lack of debugging support in Apache for both syntactic and semantic errors in config and .htaccess files is simple: either add a directive to log a given string or expression, or add a directive to call a PHP file with a given string or expression as an argument. Either way, configuring Apache would become dramatically easier, on par with writing a computer program or a website, both of which have debugging aids (detailed error messages with line numbers for compiled programs, and Developer Tools for website programming). As to security, writing a little data to the error log is usually not a security issue, but in cases where it is considered a security issue, just add a SAFE or SECURE MODE to Apache which will disable such new directives. So simple, I could almost do it myself, if Apache were easy to modify and build, which I highly doubt, its being an older product.