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

Revisit `rel=preload` as a push signal #99

Closed
yoavweiss opened this Issue Jun 13, 2017 · 10 comments

Comments

Projects
None yet
6 participants
@yoavweiss
Copy link
Collaborator

yoavweiss commented Jun 13, 2017

During the HTTP workshop, Hooman Beheshti presented on Server Push and the nopush attributes Fastly are using, as well as the home-grown x-http2-push-only attribute. The reaction from the room was... not enthusiastic.

The existence of x-http2-push-only means that people need to define "push only" hints, and I think we should provide a better way for them to do that. I also heard that rel=preload triggering push by default is something people find confusing.

I think we should revisit the decision to use preload as a push signal, as their semantics of preload and push differ enough. IMO, creating a new rel=push would enable solving all the use cases in a cleaner and less confusing way:

  • Want to push and preload? Use <link rel="push preload">
  • Want to preload but not to push? Use <link rel=preload>
  • Want to push but not to preload? <link rel=push> is the answer

Talking to the server implementers in the room, they'd happily change to such a scheme.

/cc @fastlyhoo @kazuho @icing

@igrigorik

This comment has been minimized.

Copy link
Member

igrigorik commented Jun 13, 2017

Stepping back, what's the motivation for http2-only functionality here?

The benefit, and the reason why preload is defined as it is, with preload is that an h2 proxy has the option to convert it to push, or let it through and allow the client to initiate the fetch (e.g. because it believes the client has it in cache).. Ditto for http/1 clients, which can still benefit from initiating the preload. Put differently, why would you optimize http/2 only cases here?

I'm worried that these discussions will — at the limit — seek to reproduce the full http/2 signaling layer.. which is unnecessary. If your site needs advanced control over h2 sessions with proxy.. it should communicate over h2 with the proxy, instead of falling back to http/1.

re, rel=push: we discussed before and closed see: #38.

@yoavweiss

This comment has been minimized.

Copy link
Collaborator

yoavweiss commented Jun 14, 2017

re, rel=push: we discussed before and closed see: #38.

I know, which is why the title says "revisit" :)

what's the motivation for http2-only functionality here?

@kazuho or @fastlyhoo - could you describe the use-cases that lead to adding x-http2-push-only to H2O?

@icing

This comment has been minimized.

Copy link

icing commented Jun 14, 2017

While I always promote the benefits of talking h2 between proxy and origin, this is currently not the case for a variety of reasons. And often, it is beyond the control of the web developer who want to optimise load times as experienced by the client.

I personally cannot say why a "push only" signal makes sense in this case. Assuming it does, can we offer something to signal that across a h1 connection?

Personal taste goes against rel="push"somewhat and against x-http2-push-only definitely.

rel="preload"
rel="preload attach"
rel="attach"

The notion being, if you'd send a resource in a mail, these linked resources should be attached to it. This would be more descriptive without being too h2 specific.

What I like about a special relation is that there is no need to remove the link in order to avoid the preload behaviour.

@yoavweiss

This comment has been minimized.

Copy link
Collaborator

yoavweiss commented Jun 16, 2017

Anecdotally, here is today's example of developer confusion between H2 server push and preload, which is the main reason I'd prefer an explicit "push" rel.

@igrigorik

This comment has been minimized.

Copy link
Member

igrigorik commented Jun 17, 2017

^ imo, that's mostly orthogonal, because we would have same discussion with rel=push. :-)

@fastlyhoo

This comment has been minimized.

Copy link

fastlyhoo commented Jun 21, 2017

For us, it was actually a product decision. We felt like there needed to be a way for the server to signal push, and only push, to the CDN. The Link header was already being used as the mechanism, and this discussion didn't instill confidence that there was no need for an explicit push-only option, so we added an extension to it so our customers had the choice.

The truth is that there aren't enough use cases yet, and we felt like the only way to get those use cases was to provide our customers with as much flexibility as possible. And to @yoavweiss's point (and we've seen it elsewhere too) there is confusion over the fact that the Link header is a trigger for multiple mechanisms, related or not, and may cause side-effects the user wasn’t expecting. To us, this says that the more explicit we are the better. Since the standards community wasn't giving us a way to only push, we made our own so our customers could do whatever they wanted. If/when standards get to a point to define an explicit push signal, we'll adopt it. But we didn't want our customers to wait.

I should also point out that we took things one step further and added a mechanism to trigger push via CDN configuration, which we also thought was necessary since using a server header to signal push is too late in a connection to efficiently utilize idle time to the client - a mechanism we call "async push." Again, it's about flexibility for our customers - we want them to have as many options as possible. Hopefully, that'll be an enabler for them to give us the push use cases we need to guide us down the line.

@mnot

This comment has been minimized.

Copy link
Member

mnot commented Jun 22, 2017

I'm sympathetic to that; a site might, for whatever reason, want to direct a "push" instruction to their server (e.g., mod_h2), or to their CDN, or even to one or more layers of one or more CDNs. Having different push triggers enables that.

@fastlyhoo, most of the pushback you saw in London was about the name itself. See BCP178 regarding the x-.

For the purpose you describe, I'd recommend something specific like fastly-push or cdn-push, (you might even want to support both). Registering them is pretty easy, talk to me if you're interested.

That doesn't mean that preload isn't a good push signal too -- it's just that anything pushing based upon such a signal (server, CDN, etc.) needs to be configurable as to which push triggers it acts upon.

@addyosmani

This comment has been minimized.

Copy link

addyosmani commented Jun 26, 2017

Put differently, why would you optimize http/2 only cases here?

Unsure if the reasoning is strong enough, but developer ergonomics and ease of use :)

In doing outreach around rel=preload and H/2 Push, I’ve also found Link triggering multiple, non-obvious side-effects being a point of great confusion for users. Many don't "grok" it after reading docs until they've spent a great deal of time experimenting.

I can fully appreciate the desire to not make any changes here too coupled to HTTP/2, but at the risk of being contentious: H/2 is gaining in adoption and a very explicit rel=push is much easier to reason about than the current behavior.

I wasn’t too opposed to the direction @icing was going with attempting to not be too H/2 specific, but it took a while to fully appreciate what attach was aiming to do.

@yoavweiss

This comment has been minimized.

Copy link
Collaborator

yoavweiss commented Aug 30, 2017

Closing due to lack of immediate action.
Shipping server implementations already use preload as a push signal, so we would need to keep nopush around for the foreseeable future.
I think that if we'd want to define other, more explicit push signals (e.g. rel=push) we can do that elsewhere, as it's not related to preload. If and when we do that, we could add a note here indicating such a signal as a better alternative.

@yoavweiss

This comment has been minimized.

Copy link
Collaborator

yoavweiss commented Sep 25, 2017

Yes, I closed this. Yes, I'll continue to post people that confuse preload and push here :D. Latest on https://bugs.chromium.org/p/chromium/issues/detail?id=678050

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