Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support HTTP header Link #657

Open
uasan opened this issue May 31, 2021 · 8 comments
Open

Support HTTP header Link #657

uasan opened this issue May 31, 2021 · 8 comments

Comments

@uasan
Copy link

uasan commented May 31, 2021

Hello.

I could not find a way to specify a list of resources or scope in the HTTP header:

Link: <https://example.com/dir/subresources.wbn>; rel="webbundle"; scope="https://example.com/dir/";

Will this work?
Thanks.

@bitdivine
Copy link

bitdivine commented Sep 8, 2021

I am not an expert but I note that this example also has a resources section:

<link
  rel="webbundle"
  href="https://example.com/dir/subresources.wbn"
  resources="https://example.com/dir/a.js https://example.com/dir/b.js https://example.com/dir/c.png"
/>

I have not seen the scope= in a webbundle link before. I must have missed that. Where did you find it?

@uasan
Copy link
Author

uasan commented Sep 8, 2021

I have not seen the scope= in a webbundle link before. I must have missed that. Where did you find it?

https://github.com/WICG/webpackage/blob/main/explainers/subresource-loading.md#defining-the-scopes

@hayatoito
Copy link
Collaborator

[Issue Triage]
We are now using <script> tag, instead of <link> tag, however, let me keep this open because we might want to support HTTP header to declare something for early hint-ish.

@uasan
Copy link
Author

uasan commented Sep 27, 2022

I conducted an experiment, I add a resource with Link: <submodule.js>; rel="modulepreload" headers to the bundle that refer to the files on which the given file depends, this causes the simultaneous download of all the dependencies of the requested file.

I think that it is useful to interpret these headers at the stage of generating a bundle file, for efficient sorting of the contents of the bundle, files that have the most links from other files, should be located at the beginning of the bundle body, what do you think?

@hayatoito
Copy link
Collaborator

I think that it is useful to interpret these headers at the stage of generating a bundle file, for efficient sorting of the contents of the bundle, files that have the most links from other files, should be located at the beginning of the bundle body, what do you think?

In a packaging time, I guess they can probably know the dependency graph of resources without much difficulty with static analysis. So they can package resources in topological orders or any other order they want, instead of letting bundle tools decide the order with such a heuristic.

@uasan
Copy link
Author

uasan commented Sep 27, 2022

I agree with you.
My idea was to encourage users to add the link header as much as possible, it is declarative and based on it various optimisation's can be applied in the future

@hayatoito
Copy link
Collaborator

hayatoito commented Sep 28, 2022

BTW, I wrote a small draft proposal last year:

(just FYI)
https://github.com/WICG/webpackage/blob/main/extensions/proposals/dependencies-section.md

This proposal and this issue are not directly related, however, probably share the same goal; giving a browser declarative hints so that a browser download all dependencies as early as possible.

@uasan
Copy link
Author

uasan commented Sep 28, 2022

Yes, I read, you understand the problem correctly, but I don’t see the point in additional dependency semantics, there are already semantics at the Link header level, it can be used to solve these problems.

Link headers can also be used for clients which don't support webpackage, they will make separate requests for each file and get Link headers they understand

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants