[RFC] Annotation quoting

Some customers complaining that their annotations (set by url_rewriter)
look wrong when logged to access.log. Here are a few examples of logged
annotations:
    %22-%22
    %22Default_Google%22
    %22pg13,k12%22

Currently the logging code when needs to log an annotation:
 1) first check for each note value if quotation needed (it uses the
ConfigParser::QuoteString, so it adds quotes if any non alphanumeric
char exist in string)
 2) then apply logformat quoting . This is means by default just do a
url encoding before print.

If we just remove the default logging quote, the values will be printed
inside quotes (""), but if the user wants to change quoting style, will
have the same problems.
If we remove quotes from values we may have problems, because
annotations may include comas (',') or spaces which will confuse logging.

Looks that we have the following choices to fix this:

1. Do nothing. Claim that we do not support values with commas even
though they can be passed to Squid (and Squid will correctly interpret
them) by helpers and HTTP/ICAP/eCAP agents. This is pretty bad because
customers want to use such annotations (and comma is a natural delimiter
in many cases).

2. Encode individual annotation values separately while encoding
in-value commas if needed (e.g., when using URL-encoding). This solves
the problem but adds overhead. It also makes logging somewhat
inconsistent: HTTP values are encoded as a one string, not individually,
and in-value HTTP commas are not encoded (but possibly should?).

3. Make the value delimiter configurable. The admin may be able to use a
delimiter string that will not clash with characters used inside
annotations. This is not ideal because the admin has to know in advance
what annotations are possible (to avoid clashes). This option is
probably easier to implement than option #2.

Personally I prefer 3. We can give the delimiter as argument in %note
formating code. eg:
   %{X-Name:;}note
Received on Tue Jun 18 2013 - 08:21:44 MDT