You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by "Andy Blower (JIRA)" <ji...@apache.org> on 2010/12/15 13:17:01 UTC
[jira] Created: (TAP5-1372) BaseURLSource uses getLocalPort()
rather than getServerPort()
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
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...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-1372) BaseURLSource uses getLocalPort()
rather than getServerPort()
Posted by "Andy Blower (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12972148#action_12972148 ]
Andy Blower commented on TAP5-1372:
-----------------------------------
Have you seen Igor's comment on the release vote thread?
"I see another issue here: Request interface is a generic version of HttpServletRequest and PortletRequest. As of 5.2.0 Request has the getLocalPort() method which is not available in PortletRequest. "
Just in case that makes a difference to your decision. It's fixed in our product, so it's not urgent for us, I just don't want anyone else hitting the same issue and thinking less of Tapestry.
> 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.
[jira] Commented: (TAP5-1372) BaseURLSource uses getLocalPort()
rather than getServerPort()
Posted by "Hudson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983008#action_12983008 ]
Hudson commented on TAP5-1372:
------------------------------
Integrated in tapestry-5.2-freestyle #252 (See [https://hudson.apache.org/hudson/job/tapestry-5.2-freestyle/252/])
> 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
> Assignee: Howard M. Lewis Ship
> Priority: Critical
> Fix For: 5.3.0, 5.2.5
>
>
> 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.
[jira] Updated: (TAP5-1372) BaseURLSource uses getLocalPort()
rather than getServerPort()
Posted by "Andy Blower (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Closed: (TAP5-1372) BaseURLSource uses getLocalPort() rather
than getServerPort()
Posted by "Howard M. Lewis Ship (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Howard M. Lewis Ship closed TAP5-1372.
--------------------------------------
Resolution: Fixed
Fix Version/s: 5.2.5
5.3.0
Fix experience using git svn w/ multiple branches. cherry-pick is handy!
> 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
> Assignee: Howard M. Lewis Ship
> Priority: Critical
> Fix For: 5.3.0, 5.2.5
>
>
> 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.
[jira] Updated: (TAP5-1372) BaseURLSource uses getLocalPort()
rather than getServerPort()
Posted by "Andy Blower (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Closed: (TAP5-1372) BaseURLSource uses getLocalPort() rather
than getServerPort()
Posted by "Howard M. Lewis Ship (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Howard M. Lewis Ship closed TAP5-1372.
--------------------------------------
Resolution: Fixed
Fix Version/s: 5.2.5
5.3.0
Fix experience using git svn w/ multiple branches. cherry-pick is handy!
> 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
> Assignee: Howard M. Lewis Ship
> Priority: Critical
> Fix For: 5.3.0, 5.2.5
>
>
> 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.
[jira] Assigned: (TAP5-1372) BaseURLSource uses getLocalPort()
rather than getServerPort()
Posted by "Howard M. Lewis Ship (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Howard M. Lewis Ship reassigned TAP5-1372:
------------------------------------------
Assignee: Howard M. Lewis Ship
> 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
> Assignee: Howard M. Lewis Ship
> 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.
[jira] Commented: (TAP5-1372) BaseURLSource uses getLocalPort()
rather than getServerPort()
Posted by "Howard M. Lewis Ship (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12972146#action_12972146 ]
Howard M. Lewis Ship commented on TAP5-1372:
--------------------------------------------
I can see this being important, but not quite important enough to hold off on the stable 5.2 release. It does warrant a 5.2.5 bug fix release IMO.
> 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.
[jira] Commented: (TAP5-1372) BaseURLSource uses getLocalPort()
rather than getServerPort()
Posted by "Howard M. Lewis Ship (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12972146#action_12972146 ]
Howard M. Lewis Ship commented on TAP5-1372:
--------------------------------------------
I can see this being important, but not quite important enough to hold off on the stable 5.2 release. It does warrant a 5.2.5 bug fix release IMO.
> 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.
[jira] Commented: (TAP5-1372) BaseURLSource uses getLocalPort()
rather than getServerPort()
Posted by "Hudson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983008#action_12983008 ]
Hudson commented on TAP5-1372:
------------------------------
Integrated in tapestry-5.2-freestyle #252 (See [https://hudson.apache.org/hudson/job/tapestry-5.2-freestyle/252/])
> 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
> Assignee: Howard M. Lewis Ship
> Priority: Critical
> Fix For: 5.3.0, 5.2.5
>
>
> 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.
[jira] Assigned: (TAP5-1372) BaseURLSource uses getLocalPort()
rather than getServerPort()
Posted by "Howard M. Lewis Ship (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Howard M. Lewis Ship reassigned TAP5-1372:
------------------------------------------
Assignee: Howard M. Lewis Ship
> 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
> Assignee: Howard M. Lewis Ship
> 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.
[jira] Commented: (TAP5-1372) BaseURLSource uses getLocalPort()
rather than getServerPort()
Posted by "Andy Blower (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12972148#action_12972148 ]
Andy Blower commented on TAP5-1372:
-----------------------------------
Have you seen Igor's comment on the release vote thread?
"I see another issue here: Request interface is a generic version of HttpServletRequest and PortletRequest. As of 5.2.0 Request has the getLocalPort() method which is not available in PortletRequest. "
Just in case that makes a difference to your decision. It's fixed in our product, so it's not urgent for us, I just don't want anyone else hitting the same issue and thinking less of Tapestry.
> 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.