HTTP environmental variables not found?

Hello group!

I'm a part time perl web programmer who's come up against an unusual probelm. Here's some background info.

I've put together a perl based shopping cart which makes use of cookie values to identify a specif customer's shopping cart while they are using the site. What I've noticed, all of a sudden, is the following:

When a customer cuts over from the non-secure to the secure (SSL) URL so that he can enter credit card info, etc, suddenly the HTTP environmental variables like HTTP_COOKIE and HTTP_REMOTE_ADDR are not available to Perl. Now, you might say that, well, "HTTPS" and "HTTP" are different addresses, directories, or whatever and so my HTTP environmental variable info is not available to me, or is different, BUT I didn't have this problem using another cable ISP when using my shopping cart system...the COOKIE and REMOTE_ADDR were still there and usable in the ordering process. Here's another example to help clarify things:

As a test, I set up a perl script to check for the existence of a file, which is aptly called $cookie_value."textfile.txt", where $cookie_value = $ENV{'HTTP_COOKIE'}. Now, using my usual unsecure URL path, my perl script can find the file OK using an expression like if (!(-e $cookie_value."testfile.txt")). But, when I try to look for the same file using the HTTPS directory, my script is unable to find the file. Also, it appears that the cookie was not set, and that my IP address can't be found either, using the appropriate HTTP environmental variables.

My questions are there: Is something not set up correctly on my host's Apache server such that environmental variable info can't be obtained via a perl program? Might there be something different about how my new cable ISP connects to the Internet, versus how my old cable ISP did, that precludes my being able to obtain environmental variable data...meaning is this a new security feature of SSL? Or, is the fact that my URL path is different so that I can't get this info, but then why was I able to get this info using my other cable ISP (a contradiction!).

Any help would be hugely appreciated.

Transferring cookies from SSL to non-SSL connections (and vice-versa) is a behavior that you can't depend on- for security reasons.

Users have the ability to configure their browsers to not allow this transferrance.

Your best bet is to store cart information on the server, then switch over to SSL when the user is going to check out. Create a cryptographically secure ID independent of your cookie, and pass this from the non-secure to the secure parts of your scripts in whatever session management system you prefer.

You can then match the cart to the user by matching the cryptographically secure ID back to your cart.

tell me the settings in one's browser that would be necessary to allow HTTP environmental variables to be recognized in an SSL environment.

Also, tell me why it works OK with some ISPs, and not with others. To me, this issue has not been resolved. My theory is that it's either a connection issue, or an Apache issue. Also, if you can't use cookies, or any other HTTP variable for that matter, in an SSL environment, then what use is SSL in a web programming environment? As programmers, don't we need to be able to rely on certain things working properly all of the time?

The issues involve a little understanding of TCP/IP protocol. Hero's idea is the best and only way to accomplish your task.

Say you (browser) initializes a connection to www.foo.com tcp port 80. But then you later on initializes another connection to www.foo.com tcp port 443. For your browser standpoint, you know you are the same client using the same browser connecting to the same site but to different port. For the server standpoint, the daemon running on 80 can't communicate or share environment with daemon running on port 443 as if they are completely two daemons like http and smtp, which can't speak to each other. In this case, of course, http's env can't be shared/reuse with smtp's env. To compensate this, Hero's idea of cryptographically secure ID could be used so the two daemons know something in common.

For example, say using HTTP BASIC authentication with htaccess:

Go to http://www.foo.com/private/ and log in, then go straight to https://www.foo.com/private/ without closing your browser. In this case, you will be asked again for login at https. You can immediately launch a DOS and run netstat -n and see two different connections completely isolated. For your browser, it also awares it's another connection. For you, being the user of the browser, probably don't aware the difference.

I don't make the rules the web plays by, I just program around them.

There's no maybe here. This is how things work. You'll have to figure out another sessioning method if you want to pass state information between HTTP and HTTPS connections. If you're using IE only to test if things work properly for your site, than stop. Use netscape, opera, and a few other browsers and you'll see this behavior you're relying on is completely unreliable.

I use cryptographically secure IDs embedded in a query string, and then expire the ID as soon as the user visits the page keyed to that ID. No worries about compromised user information.

The browser setting is something like "reject cookies not from the original domain," meaning, in this case, that http://www.domain.com isn't the same domain as https://www.domain.com.

However, not being familiar with your crypto methodology, can you point me to a web site that could give me a primer on the subject, and maybe an example of how this would work?

Thanks.