- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Sat, 10 Jan 2015 10:07:42 -0800
- To: Mark Nottingham <mnot@mnot.net>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
I mean that fragments are defined by media types and the type or script that is providing the fragment can tell the UA not to reuse it on redirects. Fragments have no role in HTTP. ....Roy > On Jan 10, 2015, at 9:44 AM, Mark Nottingham <mnot@mnot.net> wrote: > > Hi Roy, > > Trying to clarify… > >> On 9 Jan 2015, at 3:33 pm, Roy T. Fielding <fielding@gbiv.com> wrote: >> >> I think it has nothing to do with HTTP. > > Are you saying that this shouldn’t be a header? “It doesn’t have anything to do with HTTP” could be applied to many, many current headers. > >> The request invocation engine >> (e.g., browser) is responsible for determining whether the original >> fragment applies after the request, regardless of zero or more redirects. >> What they should do is tell the fetch algorithm to discard the fragment >> prior to performing retrieval, or at least prior to following a redirect. >> That is an internal implementation concern. > > Are you saying that it’s inconceivable that the semantics of fragment combination might be usefully hinted from the server? > >> Regardless, adding more bits for new clients won't fix the leak of >> "sensitive" information on deployed clients. I don't think adding more >> hacks to an already hacked notion of capability URLs is a worthwhile effort. > > I’d be interested in feedback from the security community about this. > > Cheers, > > > -- > Mark Nottingham http://www.mnot.net/ > > >
Received on Saturday, 10 January 2015 18:08:04 UTC