[
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.
