Open alanvoss opened 4 years ago
Thanks, Alan!
I asked him to open this here even though I think the underlying problem is likely in Erlang's packet parser since Elli just does:
parse_path({abs_path, FullPath}) ->
Parsed = case binary:split(FullPath, [<<"?">>]) of
[URL] -> {FullPath, split_path(URL), []};
[URL, Args] -> {FullPath, split_path(URL), split_args(Args)}
end,
{ok, {undefined, undefined, undefined}, Parsed};
parse_path({absoluteURI, Scheme, Host, Port, Path}) ->
setelement(2, parse_path({abs_path, Path}), {Scheme, Host, Port});
parse_path(_) ->
{error, unsupported_uri}.
So if Erlang packet parser is incorrectly returning {abs_path, Path}
instead of absoluteURI
this would happen and I think looks to be the only way it would happen.
But will need to verify this and could still be an Elli issue.
Thanks! I can have a look sometime this week.
Wishful thinking, it seems. Will try for this week. Feel free to beat me to it.
For what it's worth, this appears to be related to the contents of the packet being passed back from the prim_inet
module not containing the scheme, host, or port information. I've tested this locally on MacOS running Big Sur as well as in a container (either Ubuntu or Debian) and a POST request to a local endpoint "http://localhost:4000/create"
in a test app results in a packet starting with <<"POST /create HTTP/1.1...">>
which decodes to:
{ok, {http_request, 'POST', {abs_path, "/create"}, {1, 1}...}}
if i manually modify the same packet to pre-pend the missing info to the path: <<"POST http://localhost:4000/create HTTP/1.1...">>
it decodes as I would expect to:
{ok, {http_request, 'POST', {absoluteURI, http, "localhost", 4000, "/create"}, {1, 1}...}}
I tried to trace this back to the source but best I can tell, it appears to be coming from the C message responses generated in the erts/emulator/drivers/common/inet_drv.c
but that's above my pay grade.
Oh weird, thanks @jeffgrunewald
I wonder if we are supposed to just infer "localhost" if nothing else is there.
I was going to say the port could be taken from the socket itself but it should probably be the port in the URL and not the port being listened on, since those could technically be different.
Where should we get the URL from if it's not able to be parsed from the packet? The host
entry in the headers list? Is that something we could reliably count on to be present in a request from any given client?
FWIW, it looks like Cowboy attempts to get around this issue by primarily pulling the host from the clients’ host
header value and raising an exception if it’s not set, referring to the value being required by RFC7230 5.4: https://github.com/ninenines/cowboy/blob/2a082504996afccf78185182cd168123800bd4f0/src/cowboy_http.erl#L717
Thanks @jeffgrunewald
I opened a PR to have scheme
get set. I guess we can go with host
header for how to set the port and host.
when implementing my handle function on localhost, I was hoping to be able to utilize
scheme
,host
, andport
. I keep gettingundefined
. I admittedly am not super slick with erlang, but the rest of the application works correctly (when gettingraw_path
, for example, everything is as expected).https://github.com/elli-lib/elli/blob/21e2eeb5c718d42aca4a7014db488b4b47799450/src/elli_request.erl#L62-L67
All are undefined when this runs inside my server (though
method
properly returns).result:
calling using
curl
:System specs:
MacOS Catalina, 10.15.4
Erlang installed using https://github.com/asdf-vm/asdf :