Akka-http: Host: header is incorrectly required for HTTP/1.0 requests

[TJC]

HTTP/1.0 does not require a Host: header.

However if you attempt to query an Akka HTTP server via HTTP/1.0 without a Host: header, it responds with:

400 Bad Request
Request is missing required `Host` header

And on the server side, logs:

Illegal request, responding with status '400 Bad Request': Request is missing required `Host` header: Cannot establish effective URI of request to `/ping`, request has a relative URI and is missing a `Host` header

To reproduce

• Run up a simple "hello world" akka http server
• telnet localhost 8080
• paste in GET / HTTP/1.0

[jonas]

From my understanding, an Akka HTTP server needs to have akka.http.server.default-host-header configured to accept HTTP/1.0 requests without a Host header:

https://github.com/akka/akka-http/blob/ebfbdc22d64da42307d3c6951847e3f3cd02dfae/akka-http-core/src/main/resources/reference.conf#L102-L110

[jrudolph]

Yes, I agree with @jonas. We could try to improve the server-side log message to mention how to fix it. WDYT?

[jonas]

Yes, I can make a PR

[TJC]

Just a comment, but, I don't think documenting the default-host-header option is really the right way to fix this.
If you're not compatible with HTTP/1.0 then just reject messages immediately as such.
If you are accepting HTTP/1.0 requests, then you should not require the Host: header.

My preference would be for your HTTP server library to operate like every other HTTP server out there, and to Just Work (without workarounds or hacks) with both 1.0 and 1.1 of the HTTP standard.

As someone who writes software, I love good quality libraries that work easily and without surprises, and I'd like Akka to aspire to being one of those.

[ktoso]

Akka certainly is known for striving for high quality, and here I'd argue it was a design choice; I would not call a well documented option a hack - we may disagree but let's not get personal and offensive please - thanks.

Improving the logs is a simple first step, and we can consider additional steps if really needed.

[jrudolph]

If you're not compatible with HTTP/1.0 then just reject messages immediately as such.
If you are accepting HTTP/1.0 requests, then you should not require the Host: header.

My preference would be for your HTTP server library to operate like every other HTTP server out there, and to Just Work (without workarounds or hacks) with both 1.0 and 1.1 of the HTTP standard.

There are no workarounds or hacks needed. RFC 7230 requires that for HTTP/1.0 requests missing a Host header "the authority component is assigned the default name configured for the server", so what the user needs to do to support HTTP/1.0 is setting the default name.

We could also improve the error message sent to the client or change the default host name to some generic name to make it work without other any extra configuration. I hope you understand, though, that polishing HTTP/1.0 support hasn't been super popular with our users so far.

[TJC]

While HTTP/1.0 support might not seem relevant today, please consider that popular reverse-proxies such as haproxy and nginx use HTTP/1.0 by default, either for the proxied requests or for the health-check requests.
It is possible (via a bit of a hack in haproxy's httpchk case) to get them to look like HTTP/1.1 but it's unlikely anyone will have done that since nothing else requires it.

Thus it's easy to get into a position where Akka's HTTP implementation is causing confusion, muddled between it and the proxies. While it is possible to fix, I bet every user who comes across it will take some time to figure it out.

So, obviously, I feel like it would be a better design to be inclusive of HTTP/1.0 - but I do respect that you understand your userbase much better than I. I'm just politely trying to explain the reasons why the lack of support can cause issues in real-world situations.

Thanks for your consideration.

[jrudolph]

We fixed the error message in #619. Going forward, setting an arbitrary default host name could be also be confusing, so I don't think there's a simple solution that would make it just work for everyone.

While HTTP/1.0 support might not seem relevant today, please consider that popular reverse-proxies such as haproxy and nginx use HTTP/1.0 by default, either for the proxied requests or for the health-check requests.

Yes, nginx seems to use HTTP/1.0 by default but it will also send a host header when used in the common form with proxy_pass, so there should be no problem.

For HAProxy it seems that the default healthcheck will indeed send an HTTP/1.0 request without a Host header. The documentation, though, directly points to adding a Host header and also the answer from the server will point to what to do.

All in all, let's close this ticket for now. I don't think there is sufficient evidence so far that lots of people are affected. Lots of people are running behind a reverse proxy and AFAIK this is the first complaint so far. If someone trips over it the next time we can reopen and reconsider if additional measures are necessary.

[macheeto]

In Play Framework 2.6.7 adding akka.http.server.default-host-header = "" to application.conf file does not help:
a.a.ActorSystemImpl - Illegal request, responding with status '400 Bad Request': Request is missing required Host header: Cannot establish effective URI of request to /test, request has a relative URI and is missing a Host header; consider setting akka.http.server.default-host-header

[jrudolph]

Does it still fail if you set it to something else than the empty string?

[Flo354]

@macheeto in Play Framework, it is not the same key. The key to use is play.server.akka.default-host-header. as described here : https://www.playframework.com/documentation/2.6.x/SettingsAkkaHttp

And like @jrudolph said, the value must not be empty.

Finally, please note that this setting will not be taken in consideration when you are sending a HTTP/1.1 request and host header is missing.