Avi, why did the semantics for #urlForAction: change?

> Why did the semantics for #urlForAction: change?
>
> In Seaside 2.3, as flow advanced to the next Seaside page/component, I
> could wrap that page easily for SSL using Stunnel thus:
>
>   url := html urlForAction: [self call: MySecureComponent new].
>   self session returnResponse: (WARedirectResponse location:
> 'https://mylocalhostname', url).
>
> When the user's browser got this redirect, it would redirect to
> "https" (port 443) instead of "http" (port 80), but would otherwise
> use the complete session URL, and would connect right back to the same
> machine.  Then, stunnel would be listening on port 443, do it's SSL
> thing, and forward to port 80, where Seaside would be listening.
>
> In Seaside 2.6, at first there seemed to be just a minor change, and
> the following code looked like it would do the same thing as above did
> in 2.3:
>
>   url := html urlForAction: [self call: MySecureComponent new].
>   self session returnResponse: (WAResponse redirectTo:
> 'https://mylocalhostname', url).
>
> But it doesn't work.
> There are multiple reasons why it no longer works, but one of those
> reasons is that #urlForAction: now returns the fully qualified host
> URL (including the leading 'http://') rather than just the path
> (everything from '/seaside' on).
>
> Playing string games with the url seems to be pointless, too, because
> it *looks* like if the session keys (everything from '/seaside'
> onward) are reused, Seaside will insist that the url comes from the
> same original source.
>
> In other words, I can change the "http" to an "https" in the redirect
> string all I want, and Seaside will put it right back to an "http"
> when the request comes back, if I am using session keys that were
> originally generated from the "http" location.
>
> Hmm, come to think of it, maybe you've done something to eliminate
> session hijacking, and your "fix" is causing this issue, too?
>
> In any case, it looks like Seaside/Comanche/stunnel is no longer
> sufficient, and it is beginning to look like I'm going to need to use
> Apache and mod_ssl with Seaside, instead of just using
> Comanche/stunnel without Apache.
>
> And again, the reason I can no longer just use Seaside/Comanche with
> stunnel (without Apache) is because I can no longer get Seaside to
> redirect to the "https" location.  It just puts it right back to an
> "http".  Or so it appears.
>
> Comments?
>
> Nevin
>