You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by "Jesse Kuhnert (JIRA)" <ta...@jakarta.apache.org> on 2006/03/10 01:19:39 UTC
[jira] Assigned: (TAPESTRY-880) need 'port' parameter to supplement
'scheme' parameter for correct generation of urls
[ http://issues.apache.org/jira/browse/TAPESTRY-880?page=all ]
Jesse Kuhnert reassigned TAPESTRY-880:
--------------------------------------
Assign To: Jesse Kuhnert
> 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.0, 4.1, 4.0.1, 4.0.2
> 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: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org