Tapestry 5
  1. Tapestry 5
  2. TAP5-1372

BaseURLSource uses getLocalPort() rather than getServerPort()

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 5.2.4
    • Fix Version/s: 5.3, 5.2.5
    • Component/s: tapestry-core
    • Labels:
      None

      Description

      Line 31 of BaseURLSourceImpl:

      int port = request.getLocalPort();

      Which calls same method in the underlying ServletRequest.

      getLocalPort javadoc: "Returns the Internet Protocol (IP) port number of the interface on which the request was received."

      getServerPort javadoc: "Returns the port number to which the request was sent. It is the value of the part after ":" in the <code>Host</code> header, if any, or the server port where the client connection was accepted on."

      I think that the second is the one that should be used and since this port number is paired with the host returned from getServerName() rather than getLocalName(), this seems like a bug to me. Admittedly one that only causes problems in clustered & load balanced environments, but it's just affected our site so it would be great if it could be fixed for 5.2 final release. A final release of Tapestry should not have a bug like this in it!

      Unless anyone has a convincing argument why it should be this way, of course...

        Activity

        Andy Blower created issue -
        Andy Blower made changes -
        Field Original Value New Value
        Description Line 31 of BaseURLSourceImpl:

                int port = request.getLocalPort();

        Which calls same method in the underlying ServletRequest.

        getLocalPort javadoc: "Returns the Internet Protocol (IP) port number of the interface on which the request was received."

        getServerPort javadoc: "Returns the port number to which the request was sent. It is the value of the part after ":" in the <code>Host</code> header, if any, or the server port where the client connection was accepted on."

        I think that the second is the one that should be used and since this port number is paired with the host returned from getServerName() rather than getLocalName(), this seems like a bug to me. Admittedly one that will only rarely cause a problem, but it's just affected our site so it would be great if it could be fixed for 5.2.5 final release.

        Unless anyone has a convincing argument why it should be this way, of course...
        Line 31 of BaseURLSourceImpl:

                int port = request.getLocalPort();

        Which calls same method in the underlying ServletRequest.

        getLocalPort javadoc: "Returns the Internet Protocol (IP) port number of the interface on which the request was received."

        getServerPort javadoc: "Returns the port number to which the request was sent. It is the value of the part after ":" in the <code>Host</code> header, if any, or the server port where the client connection was accepted on."

        I think that the second is the one that should be used and since this port number is paired with the host returned from getServerName() rather than getLocalName(), this seems like a bug to me. Admittedly one that only causes problems in clustered & load balanced environments, but it's just affected our site so it would be great if it could be fixed for 5.2 final release. A final release of Tapestry should not have a bug like this in it!

        Unless anyone has a convincing argument why it should be this way, of course...
        Priority Major [ 3 ] Critical [ 2 ]
        Howard M. Lewis Ship made changes -
        Assignee Howard M. Lewis Ship [ hlship ]
        Howard M. Lewis Ship made changes -
        Status Open [ 1 ] Closed [ 6 ]
        Fix Version/s 5.3.0 [ 12316023 ]
        Fix Version/s 5.2.5 [ 12315565 ]
        Resolution Fixed [ 1 ]
        Howard M. Lewis Ship made changes -
        Fix Version/s 5.3 [ 12316024 ]
        Fix Version/s 5.3.0 [ 12316023 ]

          People

          • Assignee:
            Howard M. Lewis Ship
            Reporter:
            Andy Blower
          • Votes:
            1 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development