ap_get_server_port

[Alan Post <ap...@interwoven.com>]

Dear Sirs,

  In 2.0.16 (as in 1.3.X) it seems that ap_get_server_port, when
  UseCanonicalName is off, returns the local port the connection is bound to.

  I feel that httpd should pick up the port from the Host header, if one is
  present.  The documentation of UseCanonicalName, as I read it, indicates this
  behavior.

  It is very straightforward to see the behavior I speak of:
  
    (1) generic 2.0.16 build
    (2) set UseCanonicalName to Off
    (3) send httpd:

      GET /manual HTTP/1.1
      Host: bogus:6666

    (4) see the response redirecting us to bogus:<listen port>, instead of
        bogus:6666

  The HTTP/1.1 spec includes the following sentences:

    An HTTP/1.1 proxy MUST ensure that any request message it forwards does
    contain an appropriate Host header field that identifies the service being
    requested by the proxy.
      (http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.23)

    For 3xx responses, the location SHOULD indicate the server's preferred URI
    for automatic redirection to the resource.
      (http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.30)

  which I would interpret as allowing either behavior.

  The current behavior seems like a bug to me.  For instance, a client
  contacting httpd (listening on port 80) via an SSH tunnel might generate the
  request:

    GET /manual HTTP/1.1
    Host: localhost:12777

  only to get redirected to

    http://localhost/manual/

  which points to a different server.  It seems to me that making
  UseCanonicalName match its documentation would fix this problem without
  causing others.

  Is there something I am missing?

  Thanks for all the hard work.  Overall, I've been very happy with httpd, and
  I'm excited about the direction you folks are taking it.


      Alan Post

Re: ap_get_server_port

["Roy T. Fielding" <fi...@ebuilt.com>]

>   I feel that httpd should pick up the port from the Host header, if one is
>   present.  The documentation of UseCanonicalName, as I read it, indicates this
>   behavior.

No.  The reason we do not do this is because the security context depends
on the physical incoming port, and allowing the client request data to
override it would aloow the client to defeat the context.

....Roy