Closed abdusco closed 4 years ago
Yeah, it wasn't hardly used in v1 so I didn't make it a priority when initially building v2.
There's some (partially unconstructive) discussion here: https://caddy.community/t/http-push-in-caddy-2/8658/6?u=matt
We could probably at least support Link headers, that should cover most use cases.
As I say in that forum thread, there's room to innovate here. More sites might use the feature if it was less tedious to configure. But it is also not a very popular feature.
<link>
support would be great.
How would that work for static pages, though?
Like JAMstack websites generated with Hugo/Eleventy/Jekyl etc?
Pushing a list of assets manually would also be nice.
Something like:
push @static {
/style.css
/main.js
}
push @blog {
/blog.css
}
Right now I'm handling redirects via an import snippet generated at build and reloading Caddy after new files are deployed. I could do the same for push too.
Yeah, typically you just map requests to the resources to be pushed. Manually. It can be tedious, hence the whole "there's room for innovation" thing I mentioned in the forums.
But a basic implementation should support Link headers (not HTML tags, mind you, unless you want to buffer response bodies) and manual mappings.
Anyway, that proposed syntax looks good to me. I'd probably have recommended the same. You'll also want to consider subdirectives for specifying a method and additional headers for the synthetic request that initiates the push. v1 had this syntax:
push <matcher> [<resources...>] {
method GET|HEAD
header <name> <value>
<resources...> # one per line
}
should support Link headers (not HTML tags, ...
Definitely, I've had a brain fart there 😅. Inspecting HTML would be beyond the responsibilities of Caddy.
@abdusco Is this something you're working on?
For the record I’m (also ?) working on it. (I plan to implement https://github.com/w3c/preload/pull/149 as well as CASPer in my PR). Let me know if we can collaborate!
@dunglas Great -- yeah, so we can do a couple of things for starters:
1) Make sure that it is possible to manually specify headers to add to the push request.
2) Add experimental support for the proposed w3c draft. This might be best done in a third-party module, however, until it is standardized (i.e. separate from our standard push module, so users wanting to try the experiment would use a separate directive instead of the push
directive).
Writing Caddy modules is easy enough, especially if you have any Go chops: https://caddyserver.com/docs/extending-caddy
I'll pick this one up.
I've whipped up HTTP/2 push support in #3573. Worked well enough for me in some tests. Please give it a try!
@dunglas, if you want to use this implementation as a basis for experimenting with https://github.com/w3c/preload/pull/149, I would be happy to give any guidance on the Caddy side.
I've noticed while migrating from v1 to v2 that http2 push feature is not available in Caddy v2.
Are there any plans to bring it back?