As defined in section 4.2 of RFC 2616 the only characters legally allowed in a HTTP header are a fairly small subset of ASCII. So if we want to shove in Unicode characters they will have to be encoded in a form that only uses characters that are legal in the subset of ASCII supported by HTTP.
> -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf > Of Eran Hammer-Lahav > Sent: Sunday, July 11, 2010 8:29 PM > To: Robert Sayre > Cc: OAuth WG > Subject: Re: [OAUTH-WG] What to do about 'realm' > > > > > On 7/11/10 3:32 PM, "Robert Sayre" <[email protected]> wrote: > > > On Sun, Jul 11, 2010 at 12:27 PM, Eran Hammer-Lahav > > <[email protected]> > > wrote: > >> [this has noting to do with realm] > >> > >> Any solution should be: > >> > >> - Extensible we removed the few discovery parameters from the core > >> spec due to lack of maturity and consensus. However, we clearly have > >> enough strong interest in reintroducing them as extensions. The > >> WWW-Authenticate header is the natural place to include them. > > > > This is true. I thought it obvious that implementations would be > > required to deal with text after the "OAuth2" string. > > Yes. We need a format that can be extended. Of course, using JSON means > much richer extensibility which needs some adjustment in the registry > (maybe only require registration for top level object names?). > > >> - Human-friendly I think being able to look at the header and > >> immediately see what it means is useful. > > > > I'm not sure this is valuable, but it is possible to accomodate the > > concern anyway. I use a protocol analyzer, like WireShark. > > I think being able to curl a site and work your way manually is useful and > something that was a stated goal when we started collecting 2.0 > requirements. This was one of the reasons why the bearer token approach > was so attractive to so many people. > > >> Is there a JSON profile suitable for inclusion in HTTP headers? I > >> would like to avoid BASE64 when a person is likely to take a look at > >> the header. Otherwise debugging and command line interaction become > >> impractical. > > > > The WG could specify that all control characters and non-ASCII text > > within the JSON text be escaped. base64 adds overhead to the endeavor, > > so it's probably best to avoid it, because most of the bits will be > > ASCII anyway. > > Works for me. > > > If browser clients need to set headers in the same manner, this could > > be more inconvenient, because the JSON serializers shipping in > > browsers today don't support requiring that the produced text be > > escaped. This can be done as a follow-up pass, though. [0] > > I am not worried about client requests because there is less to debug on that > side (most issues are when the client is trying to debug on its side and can > easily add helpful information locally). I want to make sure that the server > response using the WWW-Authenticate header is plain-text and not some > encoded blob. > > However, we still need to worry about HTTP header restrictions and I am not > sure what a browser will do when you try to set an HTTP header with non- > ascii characters. > > > Using a JSON serialization neatly sidesteps several i18n issues. If > > you go with traditional HTTP header syntax, you'll need to deal with > > that some other way. btw, it just so happens that internationalization > > of Realm values is a bug in most RFC2617 implemenations. > > It would be great to avoid having to use stuff like draft-reschke-rfc2231-in- > http, but that seems to be the current solution. > > EHL > > > > > [0] (I happen to be on the ECMAScript committee, and I can be blamed > > for Mozilla's native JSON object. It would be technically easy to add > > a JSON.stringifyAsASCII() method, and I think the committee will go > > for it.) > > > > > > > > -- > > > > Robert Sayre > > > > "I would have written a shorter letter, but I did not have the time." > > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
