> In "Scheme1 realm=foo, , Scheme2 realm=foo", is the empty element an empty param for the Scheme1 challenge, or an empty challenge between the Scheme1 and Sche

> In "Scheme1 realm=foo, , Scheme2 realm=foo", is the empty element an empty param for the Scheme1 challenge, or an empty challenge between the Scheme1 and Scheme2 challenges? Answer: It doesn't matter, but good luck telling your tooling that. Yeah, I also wrote a parser generator grammar as a reference and tripped over this. I'm not real experienced with them, so it took me a bit to find the simple solution: the inner one can't consume the final comma (or the outer one won't parse due to the lack of separator, and the parser won't know to backtrack/where to), so for the inner one I just removed the portion of the rule that consumes any trailing commas. A divergence from their ABNF but oh well. > > RFC 7616's userhash field seems to require the server to do O(users_in_database) hashes to know what user to operate on; > I'd assume that you'd just store the H(concat(username, ":", realm)) as a column in the database, and select on that. I guess you're still doing O(users_in_database) hashes, but you'd do a hash when you create each user, not re-doing all of them for each request. Oh, good point. I was thinking the nonces were used in there, but they aren't. Still, it seems like such a stupid idea. The server has to maintain that extra column (per algorithm if they offer multiple), and it's just to protect the privacy of the username when the request and response are in plaintext. Who on earth thinks the username is more private than (in particular, isn't simply printed within) the actual request and response bodies? They should all be over TLS. > That was a 16 year migration period where both were supported, during which everyone "SHOULD" have switched to the new way. Right. They didn't, though. > > and it's based on old standards that followed "be conservative in what you do, be liberal in what you accept from others" so RFC 7230 section 7 has separate grammars for what lists you must send and what lists you must accept, which further complicates parsing the nested lists. > You make it sound like they totally changed it; the new list syntax is a subset of the old syntax, not something different. True, but if not for the more permissive receive format there wouldn't be the complications above.