Missing quotation mark in .htaccess line

I've got a default htaccess from 6.2 and 6.3, and they don't have that line.
A module must have added it?

Related: #295456: Bug in .htaccess file.

I propose the following lines to be added after this ErrorDocument. Fixes vim highlighting and probably others. Patch is attached.

#" This quote makes editors syntax highlighting happy
# and ErrorDocument of both Apache 1.3 and 2.x is still supported.

Proposed fix works for me in TextMate. Patch applies cleanly, too.

I'd guess that an editor with a better parser would not consider a quotation mark in a comment as ending one before the comment (unless .htaccess allows for multiline text, in which case the #line might as well be part of the message). I am passing this on to 7.x for debate.

I'm not real eager to commit this, personally. It's a minor annoyance that only applies to a few select text editors out there, in a file that is hardly ever opened by anyone.

Though we could probably use a comment there that says "This is not a bug" since this has come up at least twice now.

Yep, let's just add a comment explaining that this is not a bug.

Also note that the less changes we make to the .htaccess, robots.txt, etc. files in a stable version, the less hassle for our users. Lots of our users make custom modifications to these files, and releasing a new .htaccess just to add a syntax highlight fix for vim does not seem like the best idea to me to bother people to diff with .htaccess files while updating their Drupal 6. One more thing to think about.

I silently marked #291336: ErrorDocument in .htaccess is missing closing quote, #297024: htacces missing dbl quote in string and #290356: Add end quote to ErrorDocument 404 for favicon.ico as a duplicate of this one during the last few weeks. I'm a little fed up by the issue, so let's add a comment for this.

@10 - I've been thinking for a while that it would be really useful on each Drupal release page to make clear which of the customisable files in core (.htaccess, robots.txt, settings.php ... are there any others?) have actually changed (or if any changes are substantive). Frequently these don't change between minor releases so you can use an existing modified copy from the previous version if necessary. I think that being absolutely clear to users about whether .htaccess etc. from their current installation can be used, or not, would greatly reduce confusion and potentially make upgrading easier, therefore we would see fewer sites running old versions. Personally, I use cvs.d.o to check for any changes in these files but I doubt most people do that.

Any thoughts (apart from the fact that this needs a new issue somewhere, not sure where!)?

I recall reading upgrade paths stating no htaccess change is required so I can keep the modified old one
with that being clear on each release would be enough (even it might be stated that there were minor changes, but only aesthetic ones)

it seems to me that being an infrequently visited file is not a valid argument, since it might be otherwise a pro argument, visiting the file should be clean and self-explanatory and with the most common editors

if adding such a comment would fix some editors' highlighting I think it should be added
is just a comment that will not harm and will document a backward compatibility issue (two birds in one shot)

those who have customized htaccess will keep their versions
those who complained about the unmatching quote would have an explanation
those who doesn't care about Apache 1.3 might simply close the quote
those with highlighting problems will be happy

no harm, all pros, right?

No, we don't include workarounds in core for various text editors' quirks. If we did, we'd also include vim modelines and stuff like that... it would be a giant mess.

Still awaiting a patch that explains this is by design, to help cut down on future duplicate bug reports.

Ok, lets get this committed, I'm fed up of having to mark duplicate issues.

The patch also ups the PostgeSQL version.

+  # There is voluntary no end quote below, for compatibility with Apache 1.3

I'm not sure "voluntary" is needed; seems like this line would be fine without that word.

Oups.

Looks good.

Committed to CVS HEAD and DRUPAL-6. Thanks.

The syntax highlighting problem is not a "quirk" of some editors, it's a feature of nearly every editor.

The comparison to vim modelines is invalid, because I can get the desired result in my .vimrc file, for example. I know of no such fix for an unclosed quotation.

Here's a patch that makes things better for almost everyone and worse for no one.

In your case, matt2000, you should be asking Vim developers to re-examine why they dropped support for Apache 1.3 configuration syntax highlighting, since that is specifically what your issue is as a Vim user. If you know of many other editors that get this wrong, you should also follow-up with the developers of those editors' syntax highlighting implementations for Apache configuration files. The Drupal .htaccess file is adhering to Apache 1.3 syntax rules for the ErrorDocument declaration.

What I would suggest to the Drupal community is that we re-evaluate whether or not supporting Apache 1.3 configuration syntax is worthwhile at this point in time (or going forward in Drupal 8.0). I am not an Apache expert but I cannot really imagine 1.3 will still be an overly popular HTTP server choice by that point.

It seems like the decision really boils down to this:

• Does Drupal, by default, add an extra closing quote to the ErrorDocument message shown to users of an Apache 1.3 hosted site, or
• Does Drupal confuse new administrators, who are using editors that assume Apache 1.3 configuration files have Apache 2.x config syntax, by showing non-existent syntax errors in the .htaccess file (potentially masking actual errors later in that file)?

I would rather cater to new administrators and make their initial deployment of Drupal as easy and unconfusing as possible, than support antiquated syntax where the addition of double quote character will not break anything. The potential benefits of this change (less duplicate bug reports on this issue and less chance of novice admins making a mistake in the .htaccess file and not noticing it) are well worth the inconvenience to system admins running Apache 1.3 (they should have no problem removing the extra character if it is an issue for them).

Any counter-arguments?

Leave file how it is. Your editor is broken.