"Partially Encrypted" - mod rewrite

Have I got this right?

[rocknbil]

I'm using mod_rewrite to direct non-www. to www for all of the site except the secure pages:

http://example.com -> http://www.example.com

However I have found a problem with the CSS backgrounds. If I don't ignore the directory containing the CSS ("includefiles" below), when it goes to https it gives a "partially encrypted" warning. Viewing page info in FF reveals the images being called by the CSS are not secure.

I think I may have solved it, but would prefer not to take chances. Does this look right?

images are in /images
.css and .js are in /includefiles

Example:
.some_selector { background: url(/images/bg.gif) top left repeat-x; }

My rewrite rules, of course this board removes the spaces before the exclamation points:

RewriteEngine On

RewriteCond %{HTTP_HOST}!^www\.example\.com
# For included files, JS and CSS
RewriteCond %{REQUEST_URI}!\/includefiles\/
RewriteCond %{REQUEST_URI}!\/images\/
RewriteCond %{HTTPS}!^443$
RewriteRule (.*) http://www.example.com/$1 [R=301,L]

RewriteCond %{HTTP_HOST} (www\.)?example\.net [OR]
RewriteCond %{HTTP_HOST} (www\.)?example\.org
RewriteRule (.*) http://www.example.com/$1 [R=301,L]

If I comment out the bolded lines, I get the partially encrypted warning. ("So don't do that Bill.") Just concerned it may break something else.

[jdMorgan]

Code looks OK, but I'd advise reviewing the site design from the top down, addressing both domain and protocol canonicalization, and modifying your on-page linking methods so that this 'mixed-security' problem becomes a non-issue.

If your http and https filespaces are separate, a 'tricky' method you can use to avoid problems of resources shared between http and https is to create 'fake' image and script directories in the https filespace, and symlink these to the 'real' ones in the http filespace.

Jim

[rocknbil]

Thanks again Jim, no the filespaces are the same. I'm not sure what you mean by linking though. In pages and in CSS I link to images like so:

src="/images/filename.jpg"

Same for .js and css. What it was doing was placing the non-secure version of, say, background images:

<link rel="/include_files/my.css">

<div style="some-style">

.some-style { background:url(/images/bg.jpg); }

So it should have gone from domain root in any case, secure or not, but doesn't until I added the include_files and images directory in the rules.

[jdMorgan]

That's just weird... Any difference in the behaviour depending on the browser you use?

It seems very odd (well -- very wrong, actually) that the browser would improperly resolve a server-relative link in https to http://domain/link instead of retaining both the protocol and the domain. If this is the case with all browsers, then the only way to avoid the exclusion requirement would be to use canonical image and script links -- and that is, as I like to say, "non-optimal."

Jim

[g1smd]

Is there a <base> tag on the page setting the protocol and domain?

[rocknbil]

No difference in browsers, and no there's no base being used.

It's notable to mention though - it does not do this if I don't enable the redirect from non-www to www.

[jdMorgan]

My point being, how does a server-relative link on a page being served via SSL end up with the wrong protocol and/or the wrong domain? The browser should resolve it to the same protocol and domain as the page on which the link appears.

This is why I suggested a review of the site -- The most likely cause is that the SSL pages are being allowed to be requested from the 'wrong' domain, and therefore the links from those pages are getting redirected and breaking the http/https distinction.

Jim

[rocknbil]

Thanks again for your time Jim, I have read this 10 times on 3 successive days thinking a "light may come on tomorrow . . . " but I got nuttin'. :-) It's a Plain Jane domain, with a dynamic script for a shopping cart, the only special things going on are the .htaccess you see above, which is followed by a friendly-URL snippet which I'll paste below.

Other than that, all images, include files, etc. are requested by /, I don't use ../ or full links except for the precise links from the secure pages BACK to non-secure links, i.e.
http://www.example.com/contact.html

The rest of my .htaccess is as follows, you know what it's doing:

RewriteCond %{REQUEST_FILENAME}!-f
RewriteCond %{REQUEST_FILENAME}!-d
RewriteRule ^(.*)$ /cgi-bin/cart-script.cgi [L]

Cart-script doesn't do any special loops or rolls to the images or CSS links - these are contained in a page template, using the same syntax (/include_files/myfile.css)

Thanks again, frankly I don't know where else to look.

[jdMorgan]

Hmmm... Well, the only thing I can suggest is to fire up the "Live HTTP Headers" add-on for FireFox and watch your SSL page request and subsequent on-page image requests, and see if that indicates more precisely when and how things are going wrong.

Jim

[rocknbil]

I will put one more thought out there on this, because I am clueless. :-)

Domain root is /site.com/some-directory (like html, whatever)

CGI executables are only allowed in /site.com/cgi-bin

The only place I've seen this is in the cgi scripts. Possibly this is the issue? The .htaccess above is only located in the domain root.