Glee!

[elfs]

These mean nothing to you (but they might make sense to fallenpegasus):

foo foo&bar foo&baz&21342&$@# foo=zoom&bar&bob=ted=carol=alice foo&$= foo&%66%64%65 foo&%66%64%65=zoom %66%64%65=zoom& foo&

foo bar&foo %24%40%23&21342&baz&foo bar&bob=ted%3Dcarol%3Dalice&foo=zoom %24=&foo fde&foo fde=zoom&foo &%20foo&fde=zoom

I got the QUERY_INFO string sort and normalize function to work! Whoohoo! Now, on to the rest of the signature!

(Note the fourth example: the input fragment is 'bob=ted=carol=alice', but the equal symbol is a URI reserved character, a CGI argument, and an unreserved initial symbol separating keys from values in CGI arguments and is privileged in the standard; I made the decision to normalize the very first unescaped, but to escape every instance thereafter. I suspect this will not please some people, but it is the best interpretation I can come up with inside the mashup between the specification and RFC 3986).

(Note also the last example with the preceeding '&'; this happens when an empty argument is passed in, i.e. a QUERY_INFO contains '&&'; the empty string bubbles up to the top of the sort list according to asciibetical sorting.)

Comments

[tamino.livejournal.com]

I think you underestimate your readers' ability to interpret from context :-) I'm not familiar with the specific thing you're doing, but I'm totally familiar with the general class of problem where you want to make a hash of something, but that "something" can be in several different forms. The DomainKeys stuff for email does that with headers and whitespace, for instance, because those are two things that unfortunately tend to get rewritten and reformatted by different mail software, and you still want the hashes to compare okay. Or, machine X computes the hash using the three Received: headers that existed at the time the message was signed, but when Machine Y goes to verify it there are two extra Received: headers that weren't part of the initial hash, so what do you do? etc.

so, I look at your examples and I can see what edge cases they're intended to test for, and go "yup... yup... yup..."

congratulations for getting it all working!!

[xengar.livejournal.com]

Agreed, although the use of 'foo' and 'bar' did cause flashbacks to my college textbooks. :)

And I second the congratulations!

[bolindbergh]

Missing case 1: foo=baz&foo=&foo

Missing case 2: foo=bar%3Dbaz&foo%3Dbar=baz

[elfs.livejournal.com]

1: foo%3Dbar=baz&foo=bar%3Dbaz

2: foo%3Dbar=baz&foo=bar%3Dbaz

I realized after I posted this that there's a very big bug in the middle of it, unfortunately. It's possible to present a string of unreserved characters as a sequence of escapes, meaning they would be sorted incorrectly.

It's a very big bug, unfortunately, that's going to require some code shuffling. The code arguments are going to have to be fragmented, then normalized, then sorted, then reassembled. I was hoping to do the normalization in-place.

It would be pathological to have CGI arguments presented as both strings and a series of escape sequences, but browsers and HTTP clients have been known to do some very pathological things.

[bolindbergh]

So whoever specified this didn't supply a reference implementation and a test suite?