konstantine
How to get Phoenix to do some HTTP/2 server pushing
HTTP/2 has been around for a while, but I have not been able to find any online guidance on how to implement server push in Phoenix. My understanding is that Plug.Conn.push!/3 should do the job, but it isn’t working for me, at least not according to my Chrome and this online test. There are a few gray areas in which the culprit may be residing:
• push/3’s path: I presume that this should be the URL path with the query string, not 100% sure
• push/3’s headers: again, this might be something like [{“accept”, “text/css”}] – if necessary at all
• the port number: my https server is not running on 443, can my v2.7 Cowboy figure this out automatically? If not, where do I specify the port number?
The conn structs before and after the application of push/3 are identical, does this indicate a noop? How does one know definitively that the push has been successful?
Trending in Questions
Other Trending Topics
Latest Phoenix Threads
Latest on Elixir Forum
Sponsor Spotlight
Enabling companies to succeed by building software people love.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #elixirconf-us
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #metaprogramming
- #hex
- #performance
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Practical resources that improve the lives of professional developers.
Develop your skills with books, videos, and courses.
Bringing learning, work and compliance together since 1987.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
First 4 of 4 Posts
OvermindDL1
Are you using plug_cowboy 2.0+?
I know https has to be used or browsers won’t touch http2, I’m unsure if it will allow a different port either?
konstantine
Yes, I am using the latest Cowboy (v2.7), while Chrome confirms that my resources are downloaded using h2, i.e. HTTP/2 over HTTPS.
The requests are naturally made on port 443, but then forwarded to another port on the server (by my router). Cowboy should know about this, given that :port is supplied to the Endpoint as part of the :https list, all of which is Plug.Cowboy-related. Moreover, according to this post, a request to a port other than 443 should not be a problem.
I think that feedback is the key issue here. How do we know that the push has been successful? Is the conn struct supposed to be affected by the application of push/3, or is its operation a mere side-effect? Can we depend on push!/3 to always raise when the operation fails to push, or not?
OvermindDL1
Might need to ask one of the
@Phoenix-Core-Teampeople then (is this a good case to ping them, I code-fenced it so they aren’t…)? ^.^;konstantine
Thanks, I think I’ll simply wrap this issue up by making some final observations:
Firefox eventually showed that my server push configuration actually worked. This means that online tests like the one I used and Chrome do not necessarily provide conclusive feedback. It also means that push/3 produces a side-effect that seems to leave no trace on the conn.
Why did Chrome, in particular, not mark my resources as pushed? There are several possible reasons (incl. that server push was working), which may or may not have to do with the Phoenix implementation, but the SSL certificate (see SAN issue mentioned in the docs) was not the one responsible in my case.