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
This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:48 UTC