[ https://issues.apache.org/jira/browse/TAP5-1372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andy Blower updated TAP5-1372: ------------------------------ Priority: Critical (was: Major) 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... was: 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... > BaseURLSource uses getLocalPort() rather than getServerPort() > ------------------------------------------------------------- > > Key: TAP5-1372 > URL: https://issues.apache.org/jira/browse/TAP5-1372 > Project: Tapestry 5 > Issue Type: Bug > Components: tapestry-core > Affects Versions: 5.2.4 > Reporter: Andy Blower > Priority: Critical > > 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... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.