Thanks, solprovider. I had to look up your TLAs, but I am familiar with most of the points you make in your post, and tend to agree :)
--- On Wed, 7/30/08, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Whatever creates the URLs should look up the correct protocol. Of course, this would be ideal, but I'm not working with the ideal system, unfortunately. The CMS does not appear to provide the functionality required to achieve this. In short, navigational links are shared across pages. These are relative for all; to achieve the correct setup, I'd need these to be relative on "http://"-served pages, and absolute on "https://"; ones. Short of duplicating the navigation structure (which is not trivially small) and creating two copies to maintain, or implementing URL-rewriting logic in the application server (which lies somewhere between very difficult and impossible), I cannot see a way around this. My current solution, therefore, is to simply leave everything as is in the CMS, but implement redirects in apache to convert "https://page/should/not/be/secure"; into "http://page/should/not/be/secure"; (whose original link would have been relative: "/page/should ...") Admittedly, this is not the best solution; it's a workaround. Workarounds are always sub-optimal, but there are often things that need to be worked-around when using proprietary software. Many thanks for your feedback, - Bobby P.S. The whole reason I'm looking into this IS to ensure that all forms (yes, even the 'contact us' one) are accessed via https. If it's a choice between that setup + a nasty workaround or not having that setup, IMHO (and, I believe, yours), the former is preferable. --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: [EMAIL PROTECTED] " from the digest: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
