[webkit-dev] Request for Position: Fetch Metadata

[youenn fablet]

I also think this is worth prototyping.
Destination and mode are valuable and are hopefully not controversial, I
would start with those two.
I would also hope WPT coverage is good in that area and would cover both
regular network loads as well as cache loads. Not sure how this would play
with memory cache.

Le lun. 21 févr. 2022 à 22:07, Alex Christensen via webkit-dev <
webkit-dev at lists.webkit.org> a écrit :

> I’m interested in this work, and would be happy to review patches.  I
> noticed that Chrome and Firefox both implement it and we don’t.  Some of
> the implementation might be a little involved, so I’m happy to answer
> questions and point in the right direction when I can.
>
> I’m not thrilled that it adds more bytes to each request, especially when
> using HTTP 1.1 where headers are not compressed.  The day may also come
> when we need to either omit the metadata or send incorrect metadata for
> privacy or security reasons, but I haven’t thought it through well enough
> yet and I’m not aware of cases where that would be necessary right now.
>
> > On Feb 16, 2022, at 12:43 PM, Patrick Griffis via webkit-dev <
> webkit-dev at lists.webkit.org> wrote:
> >
> > On 2022-02-11 16:15, Patrick Griffis via webkit-dev wrote:
> >> However Sec-Fetch-User I believe will require more
> >> significant changes that will have to be exposed to each port. It
> >> requires knowing if a request was initiated by a user, exact details are
> >> specified here[2], which I think will require integration at the
> >> Safari/WebKitGTK/etc layers.
> >
> > Looking more into this Firefox takes a more heuristic approach to
> > figuring this out (was there a referrer and what is the request type)
> > and if that approach works out for WebKit it wouldn't require any
> > port-specific changes. Chromium itself does just ask the `ui` layer what
> > type of "transition" caused the request which is more in-line with the
> > spec.
> > _______________________________________________
> > webkit-dev mailing list
> > webkit-dev at lists.webkit.org
> > https://lists.webkit.org/mailman/listinfo/webkit-dev
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20220222/b8605376/attachment.htm>