akka / akka/akka-http

Clarify client-side behaviour regarding URIs and Host headers

Open
#128 3 comments 0 reactions 0 assignees View on GitHub
1 - triaged
Dominant language
Scala
Stars
1.4k
Forks
584
Avg merge
14h 33m
Merged PRs (30d)
24

Description

**Issue by [2beaucoup](https://github.com/2beaucoup)**
_Tuesday Jul 21, 2015 at 13:12 GMT_
_Originally opened as https://github.com/akka/akka/issues/18048_

---

While thinking about #18044 I looked at how we handle things regarding URIs/Host headers on the client side.

IMO this is how things _should_ behave here:
## `outgoingConnection` / `hostConnectionPool`

| URI | Host | effective URI | effective Host |
| :-: | :-: | --- | --- |
| abs | ✕ | uri | uri.host |
| rel | ✕ | uri | con.host |
| rel | ✓ | uri | host |
| abs | ✓ | uri | host |
## `hostConnectionPool` (proxied)

| URI | Host | effective URI | effective Host | Condition |
| :-: | :-: | --- | --- | --- |
| abs | ✕ | uri | proxy.host | |
| rel | ✕ | uri.copy(auth = host) | proxy.host | |
| rel | ✓ | uri.copy(auth = host) | proxy.host | |
| abs | ✓ | uri | proxy.host | host == uri.host |
## `superPool` / `singleRequest`

| URI | Host | effective URI | effective Host | Condition |
| :-: | :-: | --- | --- | --- |
| abs | ✕ | uri | uri.host | |
| rel | ✕ | | | always fail |
| rel | ✓ | uri | host | |
| abs | ✓ | uri | host | |
## `superPool` / `singleRequest` (proxied)

| URI | Host | effective URI | effective Host | Condition |
| :-: | :-: | --- | --- | --- |
| abs | ✕ | uri | proxy.host | |
| rel | ✕ | | | always fail |
| rel | ✓ | uri.copy(auth = host) | proxy.host | |
| abs | ✓ | uri | proxy.host | host == uri.auth |

Requests with a protocol of `HTTP/1.0` should be required to not have a `Host` header and therefore only the first two lines of each table and the "effective URI" column apply.

A recommendation for API users could be to never set a `Host` header explicitly and use absolute URIs for `superPool` / `singleRequest` and relative URIs in `outgoingConnection` / `hostConnectionPool` for simple requests. Akka would then add the `Host` header where required.

Implementation wise we could remove `RequestRenderingContext` and wrap the client APIs with the logic from above. Or the impl currently behaves exactly like described above? Then we have at least this nice summary. ;)

(The proxy cases are just included for completeness as this is currently unimplemented functionality.)

WDYT?

/cc @jrudolph @sirthias

Contributor guide

Open the contributing guide

Research direction

Start with the URI and Host-header behavior tables and the client entry points they name: outgoingConnection, hostConnectionPool, superPool, and singleRequest. Compare the current implementation with each case, including the noted proxy and HTTP/1.0 conditions; done requires an agreed behavior and a corresponding implementation or documented decision.

Written by the indexing model from the issue text.

Assessment

Tech stack
scala
Domain
api, networking
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.