The HTTPbis WG is tasked with cleaning up the HTTP 1.1 specification and making corrections where needed to reflect how the protocol is actually deployed. Allowing fragments in the Location header is one such adjustment.
HTTPbis is considered the authority on HTTP and even though the work is still a draft, OAuth will align itself with it because that is the best reflection of current IETF thinking. Note that this isn't new. RFC 2616 replaced 2068 which also defined HTTP 1.1 and made changes as well as dropped features due to lack of deployment experience (e.g Link header, LINK and UNLINK methods). Standards are not the word of god, just the best reflection of how interop is best accomplished in practice. EHL > -----Original Message----- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Oleg Gryb > Sent: Tuesday, August 03, 2010 3:06 PM > To: John Kemp > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0? > > > > > > ----- Original Message ---- > > > From: John Kemp <j...@jkemp.net> > > And I guess that actually the URI spec itself has been updated since > >RFC2616 (see RFC3986) and now has the fragment part included in the > >generic syntax ;) > > I don't see it in RFC3986: > > absolute-URI = scheme ":" hier-part [ "?" query ] > > Where is the fragment? The answer is: it's still in URI-reference: > > URI-reference = URI / relative-ref > relative-ref = relative-part [ "?" query ] [ "#" fragment ] > > > Well, things are a bit confusing, certainly, but it seems to me that > > a) in 2616bis, fragment in Location seems to be explicitly legal > > Unlike RFC2616, 2616bis is still a draft, right? > > b) in 2616, it is not, but if, for example, an implementation were > >attempting to conform to both the newer URI spec (RFC3986) and > >RFC2616, there might be confusion, but the fragment might well be > >parsed anyway, depending on the implementation I would guess. > > > > > > I don't understand why they didn't bump the HTTP version in 2616bis. > Apparently, they've changed the definition of very important HTTP header. > If existing HTTP clients implement strict syntax validation for the response > header, they can easily fail with the new syntax. > > > I think, the right approach would be to declare 2616bis as HTTP 2.0 and state > in OAuth 2.0 specification that it works with HTTP 2.0 only (if we really > can't > get rid of passing access token in a URL's fragment). Otherwise it's very > confusing. > > > > > > > > >> - johnk > > >> > > >> On Aug 3, 2010, at 1:39 PM, Eran Hammer-Lahav wrote: > > >> > > >>> Fragments are perfectly valid in the Location header URI: > > >>> > > >>> http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-10#sect > > >>> ion-9.4 > > >>> > > >>> EHL > > >>> > > >>>> -----Original Message----- > > >>>> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On > Behalf > > >>>> Of Oleg Gryb > > >>>> Sent: Tuesday, August 03, 2010 10:34 AM > > >>>> To: John Kemp; Brian Eaton > > >>>> Cc: oauth@ietf.org > > >>>> Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth > 2.0? > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> ----- Original Message ---- > > >>>>> From: John Kemp <j...@jkemp.net> > > >>>>> To: Brian Eaton <bea...@google.com> > > >>>>> Cc: o...@gryb.info; oauth@ietf.org > > >>>>> Sent: Tue, August 3, 2010 10:24:19 AM > > >>>>> Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth > 2.0? > > >>>>> HTTP URIs should not, when participating in the HTTP protocol, > send > > >>>>> the fragment, as this is not included in HTTP implementation > > >>>>> parsing of the URI (according to the specification). > > >>>> > > >>>> That's interesting, so if somebody puts a fragment to Location > > >>>> header, > > > >> which > > >>>> is a part of HTTP protocol, it will be a violation of the > > >>>> protocol and > >can > > > > >> be > > >>>> considered as a server side bug? > > >>>> > > >>>> See 14.2 in http://www.w3.org/Protocols/rfc2616/rfc2616- > sec14.html. > > >>>> > > >>>> > > >>>> Location = "Location" ":" absoluteURI > > >>>> > > >>>> > > >>>> > > >>>> _______________________________________________ > > >>>> 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 > > >> > > > > > > > > > > > > > _______________________________________________ > > 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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
