Re: New header for "Fragment-Scope"?

Hi Roy,

Trying to clarify…

> On 9 Jan 2015, at 3:33 pm, Roy T. Fielding <> 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.


Mark Nottingham

Received on Saturday, 10 January 2015 17:45:32 UTC