- From: Mark Nottingham <mnot@mnot.net>
- Date: Sat, 10 Jan 2015 13:09:19 -0500
- To: Roy Fielding <fielding@gbiv.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
> On 10 Jan 2015, at 1:07 pm, Roy T. Fielding <fielding@gbiv.com> wrote: > > 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. … or the media type definition could defer to a HTTP header to determine what to do. > 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/ >> >> >> -- Mark Nottingham http://www.mnot.net/
Received on Saturday, 10 January 2015 18:09:51 UTC