https mod rewrite and flash xml

flash xml not working in https and mod_rewrite

[jdavidbakr]

This is a very strange one and I'm hoping someone will be able to point out what is going wrong here. I have a site that is heavy mod_rewrite, where the pages get rewritten to an index file. I also have several flash files that access an xml page in the xml directory, so the relavent subset of RewriteRules are:

RewriteRule ^/xml/(.*)\.xml$ /index.php?redirect_page=xml&which=$1 [QSA] [L]
RewriteRule ^/([^/]*)/?$ /index.php?redirect_page=$1 [QSA]

This works perfectly in Firefox, Safari, and IE except for IE via https. https works fine in Firefox and Safari. If I remove the xml rewrite rule and actually build out the xml directory, then IE's flash sees the xml just fine and draws itself accordingly. So my question is, what is the RewriteRule sending that is different than directly sending it from the file? And why does it not work in https but does in http? Thanks for any help on this!

[jdMorgan]

Hmmm... Some preparatory work is needed.

First, the flags in the first rule are invalid. "[QSA] [L]" must be "[QSA,L]" to work as expected.

Second, completely flush all of your browser caches (Temporary Internet Files in IE) and re-test. There is no reason for any of your browsers to have acted differently. The answer to your question, "What is the RewriteRule sending that is different than directly sending it from the file?", is "Nothing - The code simply substitutes one filepath on the server for another, a process that is completely-invisible to the client.

However, speaking of the client brings up another topic -- A very common problem. How are you linking to the flash files from your pages?

If you are using page-relative links, be aware that it is the browser which resolves them, and as far as the browser is concerned, all page-relative links are based on the /xml/ directory. Therefore, you may find that these relative links are being improperly resolved, due to the presence of the "virtual directory" path in the URL. In other words, if you use '<embed src="flash-movie.swf" />' then the browser will request that from example.com/xml/flash-movie.swf. So if that is not the correct location on the server, you have a problem.

A look at both your serve access log and your server error log should make this clear.

The solution would be to use server-relative or canonical links -- that is,
'<embed src="/path-to-flash-movie.swf" />' or '<embed src="http://example.com/path-to-flash-movie.swf" />'

Jim

[jdavidbakr]

Solved it - it was PHP putting headers that made IE's flash in https angry. I added the following to my xml output script:

header("Cache-Control: private");
header("Pragma: private");

and IE's flash was happy again.

[jdMorgan]

You might also consider canonicalizing your URLs, so that HTTPS requests are redirected to HTTP when a secure connection is not required, and HTTP requests are redirected to HTTPS when security is needed. This goes along with using the proper links on your pages so that linking is also to secure/non-secure as applicable.

If you care about search ranking, you don't want any one resource on your site available at more than one URL, to include the protocol, exact domain (and subdomain), port number, URL-path, or query string.

Jim

[jdavidbakr]

The site has these flash headers on every page, only pages that require https are on https and you're redirected if you're on the wrong protocol. It was just driving me crazy that the people putting in their credit card information didn't have pretty pictures to look at in IE :)