I agree that we should assume that a lot of the RFC2616 implementations are broken, So (I am looking at you, nginx!) we shouldn't use multiple lines (anymore).
Maybe good to mention that in an OAuth implementation guide? I looked up RFC2617 and it doesn't talk about the definition of white space, leaving that to RFC2616. Though I found an example where the authorization header is on multiple lines, see http://www.ietf.org/rfc/rfc2617.txt, section 3.5 Example. An example from RFC2617 section 3.5: > HTTP/1.1 401 Unauthorized > WWW-Authenticate: Digest > realm="[email protected]", > qop="auth,auth-int", > nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", > opaque="5ccc069c403ebaf9f0171e9517f40e41" Apparently it is very difficult to correctly implement the simple header field parsing of RFC2616... :( Cheers, Marc On 23 feb 2009, at 13:39, Blaine Cook wrote: > > Ahh, ok - fair enough. Even if it's allowed by the HTTP spec, I would > be weary of spreading a header across multiple lines. ;-) RFC 2617 > doesn't explicitly allow newlines, and as such there's a good chance > that web servers or clients with special handling of Authorization > headers will trip up, so I think we should try to be conservative as > far as OAuth is concerned. > > b. > > On Mon, Feb 23, 2009 at 9:30 AM, Marc Worrell <[email protected]> wrote: >> >> On 23 feb 2009, at 10:10, Blaine Cook wrote: >> >> Thanks! Just to clarify in case others encounter this problem, the >> >> Authorization header is intended to be on a single line, and does not >> >> include newlines or carriage returns. >> >> >> Hi Blaine, >> >> Why do you say that it is intended to be on one line? >> The HTTP/1.1 spec states very clearly that any header can be folded >> onto >> multiple lines. >> Just wondering :-) >> >> - Marc >> >> >> http://www.w3.org/Protocols/rfc2616/rfc2616-sec2.html#sec2.2 >> >> HTTP/1.1 header field values can be folded onto multiple lines if the >> continuation line begins with a space or horizontal tab. All linear >> white >> space, including folding, has the same semantics as SP. A recipient >> MAY >> replace any linear white space with a single SP before interpreting >> the >> field value or forwarding the message downstream. >> >> LWS = [CRLF] 1*( SP | HT ) >>> >> > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
