[Webkit-unassigned] [Bug 181789] Link headers for subresources are not being processed

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri Mar 2 12:49:48 PST 2018


https://bugs.webkit.org/show_bug.cgi?id=181789

--- Comment #17 from Yoav Weiss <yoav at yoav.ws> ---
(In reply to youenn fablet from comment #16)
> Comment on attachment 334684 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=334684&action=review
> 
> > Source/WebCore/ChangeLog:8
> > +        Triggers Link header processing when the Link headers arrive on a subresource.
> 
> Sounds fine to me. Some suggestions below.
> 
> We might want at some point to move some important parts of loading code in
> NetworkProcess.
> Preload would also benefit from that since that would make it potentially
> faster.
> Current implementation of preloads might not be easy to move since it is
> placed in various bits.
> I wonder what your thoughts are there.

Faster sounds better :)
Is there a design doc you can share on that move?

> 
> > Source/WebCore/loader/SubresourceLoader.cpp:363
> > +    if (m_documentLoader->url() != request().url())
> 
> This cheks whether it is a subresource or a document load, right?
> I would do the check based on options.mode != Mode::Navigation.

Yeah, that's significantly better :)

> 
> > Source/WebCore/loader/SubresourceLoader.cpp:364
> > +        LinkLoader::loadLinksFromHeader(response.httpHeaderField(HTTPHeaderName::Link), m_documentLoader->url(), *m_frame->document(), LinkLoader::MediaAttributeCheck::SkipMediaAttributeCheck);
> 
> I am a little unclear on why we need SkipMediaAttributeCheck. Is there a
> spec that requires that somewhere?

This is an implementation issue. Link headers for navigations are handled in two separate location depending if they have a media attribute or not. (without media attribute they are handled before the PreloadScanner, and with it they are handled after it, once we know the viewport)
For subresources, there's no need for that check, as the viewport is already known.

> 
> > LayoutTests/http/tests/preload/link-header-on-subresource.html:10
> > +<script src="http://127.0.0.1:8000/resources/slow-script.pl?delay=400"></script>
> 
> Is there a potential flakiness issue there?
> Shouldn't we try several times to check for internals.isPreloaded until it
> succeeds?

I can change the test to do that.

> 
> Ideally, we would want these tests in WPT, right?
> We could try to use WPT server and doing preloads on URLs served by python
> scripts that would save some state.
> We would then get the state making another WPT server request, to check that
> all preloads are done/not done.

There's already a similar test on WPT: https://github.com/w3c/web-platform-tests/blob/master/preload/link-header-on-subresource.html

I should probably take some time soon to unite these test suites.
I guess I should put some time to unite those two test suites

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20180302/acc615ba/attachment.html>


More information about the webkit-unassigned mailing list