Subject: "Fragment" request header

From: Rob Sayre <[email-masked]>
Date: Thu, 6 Jun 2019 14:07:20 -0700

Is there any interest in adding a "Fragment" request header to expose that
part of the request URI to the server? It seems useful as an optimization,
and to keep "#!/" AJAX links from breaking.

Such a header would seem to be backward compatible, and could be reflected
in the "Vary" response header. It could even be an opt-in feature if
signaled in the TLS handshake.

thanks,
Rob

---

From: Daniel Veditz <[email-masked]>
Date: Thu, 6 Jun 2019 16:41:33 -0700

Hi Rob,

A lot of sites have been coded with the assumption that the fragment is a
safe place to stuff data that explicitly won't be sent to the server (in
fact that's why AJAX sites started using #! -- seems odd that now you want
to send it). Before postMessage() it was even used as a message-passing
mechanism. Changing this is not backwards compatible in the big picture.
Maybe as an opt-in, but if a site wanted to opt-in why wouldn't they just
change their URLs to put the bit they want to share in front of the #
instead of after?

When do you propose the fragment be sent? Would it start triggering loads
on each transition in an site that uses "#!" ? Or are you proposing to only
send it when current algorithms would trigger a load?

-Dan Veditz

---

From: Rob Sayre <[email-masked]>
Date: Thu, 6 Jun 2019 16:52:15 -0700

Hi Daniel, (I would say "dveditz" but I'm not sure what's appropriate here)

It seems like any site "coded with the assumption that the fragment is a
safe place to stuff data" would ignore the new header, right? The proposal
does not place the fragment in the HTTP request line.

The fragment header would not trigger any change in existing sites, but new
servers aware of the header might vary their responses. So I think sending
the fragment in a request header would be backward compatible.

A concrete example is this blog post:
https://avc.com/2011/04/finding-and-buying-a-domain-name/

The link for "Eric Friedman" is currently broken, but Twitter might be able
to efficiently vary their response if they knew the fragment identifier at
request time.

thanks,
Rob

---

From: Rob Sayre <[email-masked]>
Date: Thu, 6 Jun 2019 17:20:40 -0700

Reflecting on these objections,

I think I'll just write up an Internet-Draft. It's simple, and would avoid
prolonged email threads, by using precise language.

thanks,
Rob

On Thu, Jun 6, 2019 at 4:52 PM Rob Sayre <[email-masked]> wrote:

> The fragment header would not trigger any change in existing sites, but
> new servers aware of the header might vary their responses. So I think
> sending the fragment in a request header would be backward compatible.
>
> The link for "Eric Friedman" is currently broken, but Twitter might be
> able to efficiently vary their response if they knew the fragment
> identifier at request time.
>
> thanks,
> Rob
>

---

From: Martin J. Dürst <[email-masked]>
Date: Fri, 7 Jun 2019 05:16:56 +0000

Hello Rob,

An issue somewhat implicit in what Daniel wrote is that your header has 
privacy implications. Until now, jumping around on a single page, or 
jumping to a specific location in a page, is private, but that would 
change with the new header.

Also, Video and other continuous media are one of the places where 
sending fragment information to the server is most beneficial. This led 
to https://www.w3.org/TR/media-frags/. You can probably find reasons why 
such a header hasn't been proposed until now, and alternatives to your 
proposal, in that document, or in the discussion that lead to that document.

Regards,   Martin.

---

From: Rob Sayre <[email-masked]>
Date: Fri, 7 Jun 2019 00:31:18 -0700

> change with the new header.

This claim of privacy is incorrect, afaik. Any app with a "feed" or
"timeline" eventually writes code to track how long you look at things (via
JavaScript).

These are just the most likely sites to track you in this way, but any site
could do it, since the fragment is available to JS and can be transmitted
via XHR etc.

> proposal, in that document, or in the discussion that lead to that

I have not read that, and I will check it out. Thank you for the link.

thanks,
Rob

---

From: Rob Sayre <[email-masked]>
Date: Fri, 7 Jun 2019 00:33:03 -0700

On Thu, Jun 6, 2019 at 10:29 PM Kevin Kandlbinder <
[email-masked]> wrote:

> Hi Rob,
>
> I see a big problem in the security of the sites which use it as a way to
> store crypto data. They assume fragments to not be sent to the server, so
> no third party can intercept the request and steal the encryption key.
>

That seems like a problem, since any JS injected into the page can read the
fragment (ad trackers, browser extensions, etc).

thanks,
Rob

>
> I think even if it was opt-in many of these sites would not be happy about
> that as it would significantly reduce the security as it would help a third
> party transparently stealing the fragment. Rouge actors would not even have
> to inject JavaScript.
> How do you think that could be fixed?
>
> Kind regards,
> Kevin
>
> Rob Sayre <[email-masked]> schrieb am Fr., 7. Juni 2019, 02:20:
>
>> I think I'll just write up an Internet-Draft. It's simple, and would
>> avoid prolonged email threads, by using precise language.
>>
>> thanks,
>> Rob
>>
>>
>>>> A lot of sites have been coded with the assumption that the fragment is
>>>> a safe place to stuff data that explicitly won't be sent to the server (in
>>>> When do you propose the fragment be sent? Would it start triggering
>>>> loads on each transition in an site that uses "#!" ? Or are you proposing
>>>> to only send it when current algorithms would trigger a load?
>>>>
>>>> -Dan Veditz
>>>>
>>>>