Re: "Fragment" request header

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 <sayrer@gmail.com> wrote:

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