My bad. I forgot to update the ABNF for the parameters.
The right answer is 2 in the example below and the correct ABNF is:
credentials = "OAuth" RWS access-token RWS [ 1#auth-param ]
access-token = 1*( quoted-char / <"> )
quoted-char = "!" / "#" / "$" / "%" / "&" / "'" / "("
/ ")" / "*" / "+" / "-" / "." / "/" / DIGIT
/ ":" / "<" / "=" / ">" / "?" / "@" / ALPHA
/ "[" / "]" / "^" / "_" / "`" / "{" / "|"
/ "}" / "~" / "\" / "," / ";"
This will be fixed in -11 (already in my github [1] copy which will continue
to change with pending -11 updates).
EHL
[1] http://github.com/theRazorBlade/draft-ietf-oauth
On 7/11/10 7:17 PM, "m...@automattic.com" <m...@automattic.com> wrote:
> According to section 5.1.1, commas, equal signs, and quotation marks
> are all allowed in the access-token. How do I parse the following
> Authorization header?
>
> Authorization: OAuth vF9dft4qmT,foo="bar"
>
> 1. The access-token is 'vF9dft4qmT', and the value of some extension
> parameter 'foo' is 'bar'.
> 2. The access-token is 'vF9dft4qmT,foo="bar"'.
>
> Am I misreading the grammar? If not, I suggest access-token be defined as:
>
> access-token = token / quoted-string
>
> where token and quoted-string are taken from RFC 2616.
>
> It would no longer be ambiguous, but it is a bit confusing since RFCs
> 1945, 2068, and 2616 all define quoted-string differently. (Does that
> imply transport dependent header construction/parsing?)
>
>
> Alternatively, we could define CS as:
>
> CS = RWS "," OWS
>
> but that seems prone to implementation bugs.
>
> Mike
> --mdawaffe
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
