On 05.07.2012 08:34, Henrik Nordström wrote:
ons 2012-07-04 klockan 13:02 -0600 skrev Alex Rousskov:
No, it is not. BS is required if the body is present and BS is not a
valid key name. Thus, BS cannot be confused with a start of a
key-value
pair _and_ if a body starts with BS as well, there is no problem
because
we already know to expect a body there (after BS).
Why do we need a blob marker? Why not simply use key=value pairs
across
the board?
We need it as a temporary measure to handle old helpers responses.
I agree on the desire to move to key-pair across the board and am
trying to reach it out of this forest of individual fixed-syntax
parsers. I think its possible (easy even) to do it using a blob instead
of new config settings.
Why not have NtmlHelperReply::setResult() do the mapping? Is there
something format-incompatible with those NTLM result codes that the
generic parser cannot parse them using the following format?
[channel-ID] <result> [key-pairs] [<BS> <blob>] <terminator>
NTLM do not need a blob. It's just a value. Moving to key=value is
fine.
Additionally worth noting is that = is not a valid character in NTLM
blobs so same parser can be used if tokens without = is supported
(keyless values).
Good point here. Same stands for all the other helpers.
Alex,
before starting I went through each of the helper response styles we
have and documented exactly what comes and goes
(http://wiki.squid-cache.org/Features/AddonHelpers) to determined that
none of the response formats started with a token containing [a-z0-9]
then "=". We are *not* starting from a random-input state where <blob>
can overlap with <key>.
Anything which does not start with a registered <result> status code,
is <blob> automatically. The ones which do use <result> are safely
mapped to the key-pair format based on the presence of a valid "key="
token, or its absence indicating <blob> to be handled by the old parser.
Have a look through that wiki page at the set of "Result line sent back
to Squid" and its clear.
The proposed shared format is *exactly* what external ACL already
processes. It also if you look at the code has the proposed background
<blob> for backward compatibility with some squid-2.5 era helpers which
only sent a <reason> field in plain-text (random input! yuck, as an
established PoC it seems not to have had any complaints).
Amos
