On 05.07.2012 10:15, Alex Rousskov wrote:
On 07/04/2012 02:34 PM, Henrik Nordström wrote:
ons 2012-07-04 klockan 13:02 -0600 skrev Alex Rousskov:

Why not simply use key=value pairs across the board?

We need blobs because some values in use today are not expressed as
tokens or quoted strings (the two value formats Amos is considering).

We could, of course, _encode_ those inconvenient values so that things like SSL certificates can be represented as huge quoted strings. Is that
what you are getting at? I am not against that, even though I am a
little worried about the added encoding overhead. This will require
changing ssl_crtd helper code, but I do not think that would be a big
problem.



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.

We are talking about a general format, not NTLM-specific format. Blob is
optional. If NTLM helper does not need it, it will not use it.


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).

Yes, anonymous values or valueless names can be allowed if it helps
existing helpers. Can somebody paste a typical NTLM helper response or two?


http://wiki.squid-cache.org/Features/AddonHelpers#Negotiate_and_NTLM_Scheme

If you note, the <reason> field is usually something other than OK/ERR, so we can parse the old syntax differently to the new OK/ERR responses.

Where there is an overlap (BH) the <reason> field is an error message, usually the program name and a ':' colon (not valid in the proposed key-name) or number in brackets (again not valid in key name) or plain text message (no '=' expected on human-readable words).


Amos

Reply via email to