- From: Eran Hammer-Lahav <eran@hueniverse.com>
- Date: Wed, 21 Apr 2010 23:49:09 -0700
- To: Julian Reschke <julian.reschke@gmx.de>
- CC: "HTTP Working Group (ietf-http-wg@w3.org)" <ietf-http-wg@w3.org>
I'm not looking for a MUST NOT. But it would be nice for the spec to say "btw, you can't use fragments here". I always knew fragments are not allowed, but when asked, I couldn't show where that's defined. And because HTTP doesn't make it easy, OAuth has to make developers aware of that. EHL > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: Wednesday, April 21, 2010 11:38 PM > To: Eran Hammer-Lahav > Cc: HTTP Working Group (ietf-http-wg@w3.org) > Subject: Re: Explicit instructions on use of fragment in request URI > > On 22.04.2010 08:19, Eran Hammer-Lahav wrote: > > This came up in the OAuth WG. One of the flows used to obtain a token > relies on the fact that browsers don't sent the fragment over to the server > and uses it to encoded credentials visible only to the browser (server > provides them via a redirect Location header). I was asked what stops the > browser from sending the fragment. > > > > I spent some time trying to find where 2616 forbids including the fragment > and the best I came up with is from 3986: > > > > the fragment identifier is separated > > from the rest of the URI prior to a dereference, and thus the > > identifying information within the fragment itself is dereferenced > > solely by the user agent, regardless of the URI scheme. > > > > Mark pointed me to the definition of request-URI which is abs_path or > absoluteURI from 2396, which in turn do not allow a fragment. > > > > Would it be possible to make this easier? > > > > Something like "the request URI MUST NOT include a fragment > > component"... :-) > > Not convinced. > > a) Has this been a problem somewhere? > > b) Making a BCP14 requirement on something the syntax doesn't allow in the > first place doesn't feel right to me. If the request contains a fragment > component, it's invalid. Period. > > Best regards, Julian
Received on Thursday, 22 April 2010 06:49:54 UTC