----- Original Message ----
> From: John Kemp <j...@jkemp.net>
> To: Eran Hammer-Lahav <e...@hueniverse.com>
> Cc: Oleg Gryb <o...@gryb.info>; "oauth@ietf.org" <oauth@ietf.org>
> Sent: Tue, August 3, 2010 10:51:09 AM
> Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0?
>
> Yes, that's correct, as HTTP adopts the definition of 'absoluteURI' from the
>URI specification itself. It's just in the protocol itself that fragments are
>not sent.
>
> From RFC2616: "This specification adopts the definitions of "URI-reference",
>"absoluteURI", "relativeURI", "port", "host","abs_path", "rel_path", and
>"authority" from that specification" (where 'that' refers to RFC2396). It
>then
>proceeds to restrict URIs used in the HTTP scheme itself as being:
>
> http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]
>
> Fragments are not valid in the protocol itself, but they often are elsewhere
>(depending on the usage, and which specifications apply). As Eran says, they
>are perfectly valid in a Location HTTP header.
Definition of absoluteURI in RFC2396 doesn't include fragment. Fragment is
explicitly defined in URI-reference only.
URI-reference = [ absoluteURI | relativeURI ] [ "#" fragment ]
If authors wanted to have fragment in absoluteURI, why would they use the
syntax
above for URI-reference?
Location header is not defined through URI-reference, it's defined through
absoluteURI in the current version of RFC2616:
Location = "Location" ":" absoluteURI
The only puzzle for me is the definition and example that Eran has provided at
http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-10#section-9.4
It's a draft though, where absoluteURI in Location header definition was
replaced with URI-reference, so Location header has been redefined as follows:
Location = "Location" ":" OWS Location-v
Location-v = URI-reference
The draft will replace RFC2616 IF approved. Until then, fragments in Location
header should be considered as HTTP protocol violation, I think.
Changing definitions retrospectively in the existing protocol looks like a bad
idea: it can break some HTTP clients that expect absouteURI in Location, but
it's a topic for a different discussion.
> - 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#section-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
