W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2015

Re: New header for "Fragment-Scope"?

From: Mark Nottingham <mnot@mnot.net>
Date: Sat, 10 Jan 2015 13:09:19 -0500
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <C2E1DE91-FE6B-473B-BE1D-2587A0168422@mnot.net>
To: Roy Fielding <fielding@gbiv.com>

> 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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:42 UTC