When using SSI comments, these work: <!--#comment abc --> <!--#comment a"abc" --> but these do not: <!--#comment "abc" --> <!--#comment 'abc' --> The error is: missing argument name for value to tag comment The error comes from modules/filters/mod_include.c::find_argument() when it tries to find arguments in the comments. I think the fix is for comments to not call this function.
Hi, I think that just updating the doc to state that only: <!--#comment abc --> and <!--#comment text="abc" --> are valid syntax, should be enough. Adding a special case for 'comment' to accept ' or " would just be an ugly hack.
Well, I had no idea text= was an option for #comment. Seems you can just add any key name instead of "text"? How do you handle text with single/double quotes in them? I guess you can use double quotes for text with single quotes, and single quotes for text with double quotes, but how would you handle text with both? I assumed #comment operated just like HTML comments and went to the end of the --> block. I do think the feature is useful in allowing comments to be used without sending them to the client. What I ended up doing was to add an underscore before a single or double quote that had a space before it, but that is kind of odd.
Ah, seems this also throws the error, so it is not just quotes that are a problem: <!--#comment = -->
(In reply to Bruce Momjian from comment #2) > Seems you can just add any key name instead of "text"? Correct. I just proposed "text" that looks like a somewhat logical key name :) > How do you handle text with single/double quotes in them? > I guess you can use double quotes for text > with single quotes, and single quotes for text with double quotes, but how > would you handle text with both? Just escape the quote within the text (i.e. \" or \' or \`) > I assumed #comment operated just like HTML comments and went to the end of > the --> block. I do think the feature is useful in allowing comments to be > used without sending them to the client. Yes, it behaves mostly the same. Everything up to the closing --> is just ignored In fact, there is a special test (see [1]) that tries to spot obvious configuration issues. All mod_include elements expect parameters passed as key or key=value. If value has some spaces, there must be some surrounding " or ' or `. A key starting with a quote is not possible and is likely a missing key in fact. It is what you have hit with the 'comment'. > What I ended up doing was to add > an underscore before a single or double quote that had a space before it, > but that is kind of odd. I works for the same reason <!-- comment blah blah --> works. The parser sees your _"some text" as just a (normal) key because it does not start with a quote. [1]: http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/filters/mod_include.c?view=markup#l3203
(In reply to Bruce Momjian from comment #3) > Ah, seems this also throws the error, so it is not just quotes that are a > problem: > > <!--#comment = --> Here you are passing a key=value parameter to the "comment" element, but both the key and the value are just empty. I guess you are hitting a AH 01370 error in the log (see [1]) [1]: http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/filters/mod_include.c?view=markup#l3248
Doc updated to show the alternate syntax. r1892902 in trunk r1892903 in 2.4.x This will be visible online the next time the doc is rebuilt.
Well, the additional documentation does help, but I am not sure the logic of why and how to use it is clear. For example, if the comment contains a single quote with preceding whitespace, you use double quotes for the value. If the comment a double quote, you use single quotes, and for values with both, you use backticks. That seems very confusing for what I mentally think of as free-form comment text. What I did was to add the t="" and t='' syntax for cases that need it, and also added a cron job to check the Apache server logs for any AH 01370-style error strings. If no one else has complained about this before, I guess the documentation fix is sufficient at this point.