The variable %{HTTP_HOST} does not contain the protocol, only the hostname.
RewriteCond %{SERVER_PORT} =443
is a more universal solution, depending only on the server-defined variables. Note that this line uses the "exact string match" syntax -- which is a bit faster than a regular-expressions match, but only usable for exact matches, and thus less-frequently usable.
In your original code, there is no need to enclose your RewriteRule pattern in parentheses, as this subpattern is neither quantified nor back-referenced.
In the "HTTP" .htaccess file:
RewriteCond %{HTTP_HOST} ^www\.example\.com
RewriteCond %{SERVER_PORT} !=443
RewriteRule ^sitePage/index\.jsp$ https://site.example.com/sitePage/index.jsp [R=301,L]
In the "HTTPS" .htaccess file:
RewriteCond %{HTTP_HOST} ^www\.example\.com
RewriteRule ^sitePage/index\.jsp$ https://site.example.com/sitePage/index.jsp [R=301,L]
From your post, it is not completely clear how you intend to "draw the line" between the SSL/non-SSL areas on your site, taking into account both the protocol and the URL-space (site versus www subdomains, plus 'directories', for example.
You will likely need to define these two areas more thoroughly, so that all attempts to reach SSL "page" URLs using HTTP will get redirected to HTTPS, and all attempts to reach non-SSL "page" URLs using HTTPS will get redirected back to HTTP. Requests for shared objects such as images, css, and javascript files should be left alone -- using a negative-match pattern in a RewriteCond to exempt them from both of these redirects. Otherwise, you'll end up with the dreaded "Mixed secure/insecure content" warnings in the browser.
It will also be very important to use "absolute" links (including protocol and domain) when linking to HTTPS from an HTTP page, and to HTTP from an HTTPS page. You should not rely on/require a redirect to be invoked to handle these SSL/non-SSL transitions.
However, the examples above should at least answer your question about determining the current request's protocol.
Jim
