-
Notifications
You must be signed in to change notification settings - Fork 2.9k
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
Support dynamic port for c:Endpoint.url/0
#5553
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -351,8 +351,8 @@ defmodule Phoenix.Endpoint.Supervisor do | |
|
||
{scheme, port} = | ||
cond do | ||
https -> {"https", https[:port] || 443} | ||
http -> {"http", http[:port] || 80} | ||
https -> {"https", transport_port(endpoint, https, :https)} | ||
http -> {"http", transport_port(endpoint, http, :http)} | ||
Comment on lines
-354
to
+355
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Do we need to be so explicit about sorting through the config ourselves? Rather than special casing the times where the port is dynamic, we could just always ask the adapter for the port (I'm happy to add There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. That sounds good, but it also kinda prepends on the adapter being able to return a port / being started. That should be a simpler check though. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. That's a good point - at many of the calls we're guaranteed that the server won't be running. What ought to be the behaviour in those cases, do you think? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think if the server is not running the current behaviour (of rendering This means querying the information after startup and at best also make sure that cached information stays up to date with the bound port in case of crashes/restarts or the suspend you mentioned. |
||
true -> {"http", 80} | ||
end | ||
|
||
|
@@ -369,6 +369,39 @@ defmodule Phoenix.Endpoint.Supervisor do | |
%URI{scheme: scheme, port: port, host: host} | ||
end | ||
|
||
defp transport_port(endpoint, config, scheme) do | ||
cond do | ||
value = config[:port] -> | ||
value | ||
|> port_to_integer() | ||
|> handle_dynamic_port(endpoint, scheme) | ||
|
||
scheme == :https -> | ||
443 | ||
|
||
scheme == :http -> | ||
80 | ||
end | ||
end | ||
|
||
def handle_dynamic_port(0, endpoint, scheme) do | ||
config = | ||
cond do | ||
server = endpoint.config(:server) -> [server: server] | ||
true -> [] | ||
end | ||
|
||
adapter = endpoint.config(:adapter) || Phoenix.Endpoint.Cowboy2Adapter | ||
|
||
if function_exported?(adapter, :dynamic_port, 2) and server?(config) do | ||
adapter.dynamic_port(endpoint, scheme) | ||
else | ||
0 | ||
end | ||
end | ||
|
||
def handle_dynamic_port(port, _, _), do: port | ||
|
||
defp warmup_static(endpoint, %{"latest" => latest, "digests" => digests}) do | ||
Phoenix.Config.put_new(endpoint, :cache_static_manifest_latest, latest) | ||
with_vsn? = !endpoint.config(:cache_manifest_skip_vsn) | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would suggest plumbing through a value of
nil
for the port in the case of domain sockets; it's better than falling back to the scheme port as we're doing below.Regardless, it's an unwinnable battle either way I think.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, I saw it the other way round. If you're using unix socket nothing should even ask for a port, as that doesn't really make sense. Given the above discussion returning
nil
might be more appropriate though.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point. If we step back and observe that the goal here is to build a URI for the server, we should be asking 'what does that URI even look like for a domain socket' (and secondarily, 'is that the URI that the user cares about').
We have answers to this already in Bandit and Cowboy. If we wanted to follow down that path we should be extracting both the address and the port from the underlying server (that makes sense to me, FWIW).