request host, port, and scheme all missing when running localhost about elli HOT 8 OPEN

Wishful thinking, it seems. Will try for this week. Feel free to beat me to it.

from elli.

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.

from elli.

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.

from elli.

Thanks! I can have a look sometime this week.

from elli.

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.

from elli.

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.

from elli.

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?

from elli.

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

from elli.