1.3.29-dev actually changes the determination of the port value with UCN off in effect.
The big question is if the client does NOT send a Host header, and UCN is Off, should the port be the port number used in the connection socket OR should we use whatever Port is set to... The current implementation, which I think is correct, is to use the physical port number... The intent of UCN Off is to say, basically, "trust whatever the client sends you, as far as hostname and port number..." and with that in mind, I think we should trust what port the client is talking to in absence of Host (since that is closer to the goal of Apache's concept of host:port not being the final or high priority authority).
Also note that what 2.0 and what 2.1 does as far as ap_get_server_port() with a non-existent Host header are different... 1.3.29-dev follows the 2.1 logic.
On Dec 19, 2003, at 11:04 AM, William A. Rowe, Jr. wrote:
UseCanonicalName On -or- UseCanonicalName Off, but the Host: header was missing (e.g. HTTP/1.0)
In 1.3 - the host's {ServerName}:{Port} is returned.
In 2.0 - the host {Servername} is returned (must include port suffix).
there were no surprises there.
UseCanonicalName Off, Host: header provided (HTTP/1.1)
The host name header *excluding the host header port suffix * of the request
is concatenated to httpd 1.3's Port directive setting or the real port number
in httpd 2.0.
Now this might appear to be a moot issue, but if a proxy that doesn't mangling
headers bounces requests from port 80 to another server's port 8080 attempting
to impersonate the front end proxy, everything should work, in theory, with
UseCanonicalName Off. As it turns out, UseCanonicalName must be turned
on to avoid the port :8080 suffix from being appended to the redirects.
Host headers (from my usual clients) do appear in the form
Host: localhost:8080
when the request http://localhost:8080/ is sent. UseCanonicalName Off docs
state outright that we use the Host: header provided by the client. The example
above shows that we do not. But if we correct the behavior, instead of the docs,
then perhaps users will commonly end up with broken configs.
So I'm wondering what the consensus is - fix the docs, or the behavior?
Bill
