- From: Mark Nottingham <mnot@mnot.net>
- Date: Sat, 10 Jan 2015 12:44:54 -0500
- To: Roy Fielding <fielding@gbiv.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
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 17:45:32 UTC