On 2011-10-10 01:08, Manger, James H wrote:
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),
It is possible. There is code out there that does it.
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]
It still is a violation of the spec if you do so.
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.
Again, if you believe this is a good idea, the place to argue this is
the HTTPbis WG, and not inventing something specific for OAuth.
Best regards, Julian
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
