search

WICG / webpackage

Web packaging format
Other
1.22k stars 114 forks source link

Support HTTP header Link #657

Open uasan opened 3 years ago

uasan commented 3 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 1 year ago

[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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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