By definition the header ABNF is going to limit the allowed characters. There
is no way around that. As of right now, the only problem is with the token
value because the other fit well with the 'token' ABNF. The signature is
already base64 encoded and included as a quoted string.
So the questi
> We will need to choose an encoding method for the header values
Not if we restrict the allowed chars in tokens to a very safe set of ~64 chars.
> and percent-encoding seems to make the most sense
It makes sense in URIs. In HTTP headers, however, I think it is more novel.
There are quoted stri
sing these opaque values
> around don't have to do any escaping. They should just do input validation
> (reject values with any disallowed chars).
>
>
>
> P.S. 'token' may be changing in the revision of HTTP currently being written.
>
>
>
> --
&
ntly being written.
--
James Manger
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran
Hammer-Lahav
Sent: Friday, 16 April 2010 3:57 AM
To: OAuth WG
Subject: [OAUTH-WG] Issue: restriction on values characters
Given the current proposal for
I trust your experience here, so +1.
On Thu, Apr 15, 2010 at 10:56 AM, Eran Hammer-Lahav wrote:
> Given the current proposal for signatures (no parsing of the request URI or
> body, or any encoding), I would like to proposal that the spec remains mute
> on the allowed parameter values.
>
> While
Given the current proposal for signatures (no parsing of the request URI or
body, or any encoding), I would like to proposal that the spec remains mute
on the allowed parameter values.
While it is best to issue values that do not require any encoding (or
decoding when receiving a token response),
