On 7/31/08, Bobby Jack <bobbykjack@xxxxxxxxxxx> 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, solprovider@xxxxxxxxxx <solprovider@xxxxxxxxxx> 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: users-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|