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

[Nevin Pratt]

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