Clarify client-side behaviour regarding URIs and Host headers
- 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
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