How to do HTTP/2 Push in Caddy 2,
I tried using Link header
header Link "</bmw.jpg>; rel=preload; as=image"
but for me it looks like it doesn’t work
I think you’re asking for the equivalent of the push directive from Caddy v1, right?
https://caddyserver.com/v1/docs/push
Unfortunately that functionality hasn’t yet been ported to Caddy v2. You’re the first person to ask about it since the v2.0 release, I think.
Could you open a GitHub issue to track it as a feature request?
FWIW I think it could also be easily implemented as a plugin/module response middleware.
Thanks!
Yeah that’s what I was talking about, I’ll do that
I think it should definitely be implemented cause it’s great, especially since HTTP/2 is the whole point of the Caddy server
Well, it’s one of many reasons to use Caddy, not “the whole point”. Just saying.
For me it was HTTP/2, Auto SSL/TLS and Caddy’s simplicity
Caddy serves HTTP/2 by default.
We learned in v1 that almost no one uses the server push functionality of HTTP/2, so it hasn’t been an implementation priority. Besides, configuring it is awkward at best. No one has really come up with a great way to expose push configuration that isn’t tedious. You basically have to map every possible request where you want to push to all the subsequent resources associated with them.
There’s room for innovation here, and that is never an easy or fast process.
FWIW that’s not too hard to do from the backend app, you just need to keep track of which assets you put in each HTML template and set a Link header for each of them.
I did this in my PHP app a while back by putting a thing like this in my PHP template beside my assets (where push_asset is a helper function that just sets up the Link header).
<head>
...
<link rel="stylesheet" type="text/css" href="css/app.css">
<?php push_asset("css/app.css"); ?>
...
</head>
@matt Do you see any downside at all to just take any Link headers and push them along, by default? I’m not sure if there’s any reason to not do it. I guess maybe the header lookup in the response could be considered some minor overhead, but I really don’t think it would be enough to matter?
2 Likes
That’d be a good start – maybe only if it has a preload resource hint: Preload. And honor the presence of nopush.
2 Likes
Yeah I agree, I too have script on my WordPress sites that automatically and dynamically writes Link preload headers for CSS/JS requests, but I’ve always had to use Cloudflare for delivering those Push requests, it would be great to be able to do it in Caddy server
Hi, I’ve been watching on Caddy since a while (1 year, about).
Now release v2 looks great - and I decided to make some experiment.
Unfortunately I discover http2-push isn’t supported anymore, a bit strange and block me to make any further tests.
You redesigned Caddy2 to be ready for enterprise and I think you achieve it.
But you are still thinking about previous audience that used v1 as main customers.
Just a point of view, but v2 for a product means also v2 for a new audience and many enterprise company (+ individuals developer) use Http2-push 
Yeah I completely agree with you @julio2008 that’s just wrong to remove HTTP/2 Push which is/was a great feature, and it’s one of the many upsides of using HTTP/2 capable web server.
It’s not “removal”.
It just hasn’t been “re-added” yet.
Caddy v2 is a complete internal rewrite from the ground up compared to Caddy v1.
2 Likes
Hi,
For the record, the Preload specification is natively supported by Symfony and API Platform (PHP frameworks).
If you’re interested in getting this feature back in v2, I would be happy to work on it.
3 Likes
Sure, that’d be great. Please submit a proposal on GitHub and we’ll talk about it!
3 Likes
This topic was automatically closed after 30 days. New replies are no longer allowed.