> You can't "replace" quoted-string. > > A recipient will have to be able to parse multiple challenges in a > single header field value. To do so, it has to understand the syntax of > params using double quotes. It can't special-case the parsing based on > what part of the set of challenges it currently is looking at (because > to do so, it needs to have parsed them first).
Parsing is not affected. Only un-escaping after parsing. Even if you did generic un-escaping before reaching code that understood a specific parameter (and I'm not sure that is likely), you still don't need to special-case the un-escaping. You can interpret it all like JSON as no quoted-string value in practise will escape an alphabetic letter (a-z). Not only would it be pointless for the sender to do so, they would also be violating a "SHOULD NOT" in the spec. Senders SHOULD NOT escape octets in quoted-strings that do not require escaping (i.e., other than DQUOTE and the backslash octet). [draft-ietf-httpbis-p1-messaging-16#section-3.2.3] > If we were free to change things, we'd simply state that everything is > UTF-8. But that would break things. I am only suggesting changing the interpretation of \u because I don't believe it will break any existing values. > But that argument doesn't change the fact how it is defined. Changing defined behaviour is not great. Changing defined behaviour that is *never used* (eg "\u" as an escape sequence for "u") doesn't sound so unreasonable. -- James Manger _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
