Re: "Fragment" request header

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.



On 2019/06/07 09:20, Rob Sayre wrote:
> 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
>>>
>>>
>

Received on Friday, 7 June 2019 05:17:24 UTC