Torben,
Thanks for the reply. I didn't know that other scripts relied on that context as well. Sounds like changing that could cause a total nightmare! :-|
Certainly, setting the context to 'users' has solved both of the problems ( i.e. 1. failure to re-direct to https, and 2. warning about complete urls not being permitted) so in that respect at least I am a happy bunny again.
I suppose there is no absolute need to have seperate listeners for Aolserver virtual servers since a single instance of Aolserver could handle any number of virtual domains using a single listener on a single https port anyway. If we wanted to use the outgoing context (i.e. for an ecommerce payment gateway), there is nothing to stop us configuring any number of additional named contexts for the purpose.
Perhaps someone much more knowledgeable than me would know whether there are memory and resource benefits to having a listener per domain for Aolserver virtual servers? For my own part I prefer to run a server for each OpenACS anyway so that I can shutdown and restart each domain without affecting any others. In other words, I probably wouldn't use the feature myself!
This probably comes under the category of nice to do from a philosophical point of view, but lots of work to no great benefit! Nevertheless, I would be happy to help and contribute if a consensus emerges. I set my config.tcl up according to the Aolserver docs and I think the onus would be on the OpenACS code to correctly inspect the config data for the context declaration using ns_config rather than making naming assumptions.
In any case we probably ought to check that somewhere it is documented that this nsopenssl context is currently hard-coded as 'users'.
Also, one of the kernel maintainers will need to update security::locations to correct the typo I found.
Best Regards
Richard
