[ http://issues.apache.org/jira/browse/TAPESTRY-880?page=all ]
Fernando updated TAPESTRY-880:
------------------------------
Attachment: backwards.patch
Here is the patch to add deprecated backwards compatible methods.
> 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
> Fix For: 4.0.1
> Attachments: backwards.patch, portdocs.patch, 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]
