On 7/31/08, Bobby Jack <[EMAIL PROTECTED]> wrote: > 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 :)
I assume you know URL, CMS, and SSL. TMI = Too Much Information - I was halfway into a rant and used the TLA question as an apology if reading the extra text was wasting your time. HTH = Hope This Helps - Very common closing on support mailing lists. FYI (For Your Information), "IIUC" = If I Understand Correctly - used later in this post. (OK. a four letters is not a TLA.) > --- 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. Agreed. IIUC, HTTPS pages contain relative links that are not currently available using HTTPS -- you are attempting to internally serve the pages by internally redirecting the URL to the HTTP server. A solution is let HTTPS try to serve the page. If this fails, pass to a CGI program that attempts to find the page with HTTP. If the page still cannot be found, return an error page. ErrorDocument 404 /cgi-bin/TryHttpBeforeErroring TryHttpBeforeErroring pseudocode: If REDIRECT_SERVER_PORT = 443 Then Get page from "http://"; + REDIRECT_SERVER_NAME + REDIRECT_URL If success, send page and exit. For all other cases, return a "Not Found" error page. RewriteRules would not require a CGI program, but requires that httpd differentiate between HTTP and HTTPS pages. Using ErrorDocument does not require the differentiation -- pages are automatically served by the best method without affecting the browser. Disclaimer: Use the ideas in this post at your own risk. I have not tested anything. HTH, solprovider --------------------------------------------------------------------- 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]
