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

[bugzilla-daemon at webkit.org]

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

youenn fablet <youennf at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #334684|review?                     |review+
              Flags|                            |

--- Comment #16 from youenn fablet <youennf at gmail.com> ---
Comment on attachment 334684
  --> https://bugs.webkit.org/attachment.cgi?id=334684
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.

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

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

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

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.

-- 
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/f5f34212/attachment-0001.html>