Uploaded image for project: 'JBoss Enterprise Application Platform'
  1. JBoss Enterprise Application Platform
  2. JBEAP-6130

[GSS](7.1.0) proxy-address-forwarding has not effect when Host header is present

    XMLWordPrintable

Details

    • Bug
    • Resolution: Done
    • Major
    • 7.1.0.DR6
    • 7.0.1.GA
    • Undertow
    • None
    • Hide

      1. Set `proxy-address-forwarding="true"` on http-listener:
      2. Deploy jsp that logs out request.getServerName/getServerPort/etc.
      3. Make request with X-Forwarded-* headers present:

      # curl -H "X-Forwarded-Host:myhost" -H "X-Forwarded-Port: 80" http://localhost:8080/sample_proxynameport/hello.jsp
      request.getServerName() => localhost
      request.getServerPort() => 8080
      request.getScheme()     => http
      
      Show
      1. Set `proxy-address-forwarding="true"` on http-listener: 2. Deploy jsp that logs out request.getServerName/getServerPort/etc. 3. Make request with X-Forwarded-* headers present: # curl -H "X-Forwarded-Host:myhost" -H "X-Forwarded-Port: 80" http: //localhost:8080/sample_proxynameport/hello.jsp request.getServerName() => localhost request.getServerPort() => 8080 request.getScheme() => http

    Description

      If I configure `proxy-address-forwarding` for my http-listener, reqeust.getServerName and request.getServerPort still return the hostname/port from the Host header in the request. I would expect if `proxy-address-forwarding` is configured that the Apache proxy's hostname/port would be returned.

      I noticed that when I make a curl request with an empty Host header (like below) that the X-Forwarded-* headers are picked up by getServerName/getServerPort.

      Whereas, if I set Host header to empty it works:

      # curl -H "Host:" -H "X-Forwarded-Host:myhost" -H "X-Forwarded-Port: 80" http://localhost:8080/sample_proxynameport/hello.jsp
      request.getServerName() => myhost
      request.getServerPort() => 80
      request.getScheme()     => http
      

      However, not having a Host header is bad HTTP/1.1 and in future Undertow release the "workaround" above will not work (UNDERTOW-786).

      Attachments

        Issue Links

          Activity

            People

              rhn-support-iweiss Ingo Weiss
              jbilek@redhat.com Jiří Bílek (Inactive)
              Jan Stourac Jan Stourac
              Jan Stourac Jan Stourac
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: