[ http://issues.apache.org/jira/browse/TAPESTRY-880?page=comments#action_12369864 ]
Jesse Kuhnert commented on TAPESTRY-880: ---------------------------------------- It would be nice if a documentation patch accompanied this. A lot of the unit tests failed but I fixed them. > need 'port' parameter to supplement 'scheme' parameter for correct generation > of urls > ------------------------------------------------------------------------------------- > > Key: TAPESTRY-880 > URL: http://issues.apache.org/jira/browse/TAPESTRY-880 > Project: Tapestry > Type: Bug > Components: Framework > Versions: 4.1, 4.0.2, 4.0.1, 4.0 > Reporter: Fernando > Assignee: Jesse Kuhnert > Attachments: schemeportsupport.patch > > There are lots of components ( Form, LinkComponent, etc ), which allow you to > change the destination scheme, but I don't think that is enough. Issue > TAPESTRY-786 tried to bring this to light, but wasn't clear, and marked > resolved incorrectly. > The issue is that if I were to change a url from HTTP to HTTPS, then I have > to change the SCHEME AND PORT. > HTTP/80 --> HTTPS/443 > or more apt during development: > HTTP/8080 --> HTTPS/8443 > I can't simply change the scheme: > HTTP/80 --> HTTPS/80 > HTTP/8080 --> HTTPS/8080 > because I do not ( and I don't think I can even set this up ), a webserver > listenting for both HTTP and HTTPS traffic on the same port. > Also there is no way for the system to just KNOW what the destination port > will be. We could have some heuristics, like if HTTP/80 --> HTTPS assume > 443, or HTTP/8080 --> HTTPS assume 8443, but what of all the other random > ports that we setup for testing and various reasons... > ** I think we at least need to expose the destination port as a parameter as > we now expose the scheme. ** So I will submit my patch that will do this. > At the moment it is against tapestry/trunk, but I think this should be back > ported to encourage it's earlier release. > ( We could even roll in the ability to change the destination HOST, or even > the destination CONTEXTROOT, but those would be enhancements rather than > required fixes. And we could be opening up a pandoras box. ) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
