Re: "Fragment" request header

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

On Thu, Jun 6, 2019 at 4:41 PM Daniel Veditz <dveditz@mozilla.com> wrote:

> 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
>
>