search

evert / push-please

A proposal for a HTTP-client suggested push by link-relation
4 stars 0 forks source link

Should we support the as="script" parameter #8

Closed evert closed 5 years ago

evert commented 5 years ago

When a server wants to suggest a browser or intermediate to preload a resource this unfortunate syntax was chosen:

Link: </style.css> rel="preload" type="text/css" as="style"

The as part can contain other strings such as:

W3c spec here: https://w3c.github.io/preload/

Should Prefer-Push support this? Potentially in this form:

Prefer-Push: rel; as="script"

The argument is that for the above list, not every item in as has an associated rel-type. It's therefore not possible for example for a browser to request every video to be pushed with:

Prefer-Push: video

Because the W3C spec has defined this with a new as attribute and always uses the preload rel, a possible way to express this could be:

Prefer-Push: preload; as="video"
sebdeckers commented 5 years ago

The goal here is for a useragent to specify what it considers necessary to be pushed. E.g. latency sensitive apps like browsers might want to load only critical rendering path resources like CSS, JS, fonts. That way the server does not spend effort pushing images or video assets from the page.

This could work for browsers natively but I'm thinking more about JavaScript based resource loaders relying on H2 Server Push as opposed to file concatenation bundling. The main advantages being atomic resource caching and invalidation, with zero-conf setup for frontend developers.

An alternative to as would be to (propose to) register these rels for script, document, etc.

sebdeckers commented 5 years ago

BTW What about other attributes?

evert commented 5 years ago

I think the Web Linking attributes are interesting, but note that RFC8288 is now the latest version.

I think the question really becomes, do we want the "kitchen sink", or is it best to try and keep things simple. The proposal started with: Push-Please: rel1, rel2. If we're opening the door to as, there's definitely other major candidates that start to make sense. The biggest one that comes to mind is type, which might actually also solve your problem:

Prefer-Push: rel; type="text/javascript"

Notable is that not even the much newer RFC8288 considers as. I suspect this is because it doesn't really make that much sense to exist and is a bit of a hack to make an existing hack (`rel="preload") work in an expanding use-case.

sebdeckers commented 5 years ago

Good point about keeping it simple. If as is not required for the API use case, don't include it. Perhaps this resource bundling hints use case can be explored separately.

awwright commented 5 years ago

I don't think you can, the HTTP Link header doesn't define any "as" parameter. There's no standard registry of link parameters, each media type defines its own.

Further, that syntax doesn't make much sense to me. Does that mean you could do

Prefer-Push: style; type="text/css"

?

In the larger scope, I think there's two other improvements we should forward to the appropriate bodies:

  1. There should be a link relationship for importing scripts, the same way CSS does

  2. Preload should not define new link attributes, but should specify different link relationships for different subresources. preload-script is a fundamentally different link relationship than preload-image. A user agent might want to load images but not scripts, for example.

evert commented 5 years ago

There should be a link relationship for importing scripts, the same way CSS does

I agree. script, font, and others.

Preload should not define new link attributes, but should specify different link relationships for different subresources. preload-script is a fundamentally different link relationship than preload-image. A user agent might want to load images but not scripts, for example.

Do you still need preload if Prefer-Push is supported? At the very least for 'server-driven' preload it doesn't make that much sense anymore.

evert commented 5 years ago

There should be a link relationship for importing scripts, the same way CSS does

I agree. script, font, and others.

  1. Do you still need preload if Prefer-Push is supported? At the very least for 'server-driven' preload it doesn't make that much sense anymore.
evert commented 5 years ago

I'm closing this ticket because I think solving this is outside the scope of this specification

awwright commented 5 years ago

So I just realized "preload" tries to define an "as" which I guess satisfies the "extension attribute" section in https://httpwg.org/specs/rfc8288.html#extension-attributes.

What HTTP Link really needs is a registry of link attributes, instead of letting HTML define the semantics of a link. (But this is beside the point.)

I think we should still pursue how to request pushes of scripts, even perhaps pursuing some upstream changes. Maybe register a "script" relation, that has some semantic equivalence to HTML's script tag.