[jon31]

Hi Folks,

When I redirect users in my shopping cart to https (secure) pages using the header redirect function, and they have their Mac OS X firewall enabled, they get stalled out and cannot continue. If you try to access a secure site on my domain via a link, or javascript location.href, it loads fine, but if I try to redirect with a PHP header redirect, it stalls out and doesn't load.

Does anyone know why this might be happening only with header redirects? Or know of any work-arounds that I could try to fix it?

I'm desperate here

Jon

[besson3c]

Originally Posted by jon31

Hi Folks,

When I redirect users in my shopping cart to https (secure) pages using the header redirect function, and they have their Mac OS X firewall enabled, they get stalled out and cannot continue. If you try to access a secure site on my domain via a link, or javascript location.href, it loads fine, but if I try to redirect with a PHP header redirect, it stalls out and doesn't load.

Does anyone know why this might be happening only with header redirects? Or know of any work-arounds that I could try to fix it?

I'm desperate here

Jon

I think your assessment might be inaccurate. The OS X firewall ruleset blocks incoming connections, but permits all outgoing connections. Your website is not pushing data out to other machines, your visitors are simply downloading this content.

Do you have a text-based browser with SSL enabled installed on your webserver? I'd try to access the page from there. Is this a new SSL certificate? Does it work?

[jon31]

If users are downloading content from my site, ie. the pages, doesn't that mean my server is pushing data to them, over the secure port?

Yes, the certificate works. You can see it at: https://www.macprovideo.com/cart/. It seems to verify correctly and whatnot.

And no, I don't think I have a text based browser installed on my server. Our server is hosted by MediaTemple, who are terrible with any sort of tech support.

[besson3c]

Originally Posted by jon31

If users are downloading content from my site, ie. the pages, doesn't that mean my server is pushing data to them, over the secure port?

No, it means that the user's web browser is requesting this data from the web server. If the user's firewall was relevant, that would mean that any OS X user that enables their firewall wouldn't be able to view any web pages, as port 80 is not running by default. This problem is definitely server side.

And no, I don't think I have a text based browser installed on my server. Our server is hosted by MediaTemple, who are terrible with any sort of tech support.

So obviously you don't have access to the Apache logs either, right?

[jon31]

I have access to Plesk. I may be able to find Apache logs. Are you saying server-side as in server configurable or my scripting that's causing it? It seems that the only way it stalls is if I redirect a user using the PHP header location function.

[besson3c]

Originally Posted by jon31

I have access to Plesk. I may be able to find Apache logs. Are you saying server-side as in server configurable or my scripting that's causing it? It seems that the only way it stalls is if I redirect a user using the PHP header location function.

Show us your redirect statement, the URL causing the problem, and the original URL if you could please...

I very much doubt you'll have access to teh Apache logs unless you admin the server. What I meant by server-side was the Apache/SSL configuration, but it can't hurt to check out your scripting too, if you don't mind...

[jon31]

Sure, here's an example of the process:

Step 1: Add items to cart, then hit Checkout (This uses javascript to jump to the secure cart area)
Step 2) Enter your customer information then hit Continue (this now uses PHP to redirect to step 3 - originating link is: https://www.domain.com/cart/checkout/step2)

// Direct user to step 3
header("Location:https://www.domain.com/cart/checkout/step3");
exit;

That's all I have. But again, if you click between the secure pages using javascript or href links, there's no lag. Only when redirecting with PHP.

I really appreciate your time and help on this.

[Edited to include https rather than http]

[besson3c]

Originally Posted by jon31

Sure, here's an example of the process:

Step 1: Add items to cart, then hit Checkout (This uses javascript to jump to the secure cart area)
Step 2) Enter your customer information then hit Continue (this now uses PHP to redirect to step 3 - originating link is: https://www.domain.com/cart/checkout/step2)

// Direct user to step 3
header("Location:https://www.domain.com/cart/checkout/step3");
exit;

That's all I have. But again, if you click between the secure pages using javascript or href links, there's no lag. Only when redirecting with PHP.

I really appreciate your time and help on this.

[Edited to include https rather than http]

Have you tried basing your redirect relatively?

header("Location: ../step3");


Did you write this yourself? I'm not sure how wise it is to create a whole new URL space for each step. What if a visitor just right away goes to:

https://www.domain.com/cart/checkout/step3

by entering this in his/her browser? The URL that people see is virtually irrelevant since you can do URL rewriting to present more human readable URLs while masking the URL for the page actually being served. I'm not sure you gain much in organization or maintainability either actually creating separate directories for each step.

What I might do is something like this

create a checkout.php file, in this file:

Code:
$cur_step = $_GET['step'];

if ($cur_step == 1) {
include 'step_one_stuff.php';
}
elseif ($cur_step == 2) {
include 'step_one_stuff.php';
}

etc.

Just offering some additional suggestions here, not really related to your original problem.

[jon31]

I originally had relative links to begin with, then read that the PHP header redirect requires direct links, so I've updated them accordingly.

As for the separate directories, it actually uses mod_rewrite, there's only the one directory, and uses the if/else statements you described. Glad to see we're on the same wavelength though.

And yes, it's all custom coded by me, which is why it doesn't work perfectly

[besson3c]

Originally Posted by jon31

I originally had relative links to begin with, then read that the PHP header redirect requires direct links, so I've updated them accordingly.

As for the separate directories, it actually uses mod_rewrite, there's only the one directory, and uses the if/else statements you described. Glad to see we're on the same wavelength though.

And yes, it's all custom coded by me, which is why it doesn't work perfectly

We're kind of hanicapped here then, with no way to look at the logs or really get into what is going on here... I guess this is one of the problems of having a third party host your site.

Have you thought about debugging this on a personal machine of yours that you have admin access to?

[jon31]

Yes, it is very unfortunate that we have to run a virtual dedicated server through someone else. The plan is to get an xserve running in our office soon, but there's no fibre optics in our building yet to handle the bandwidth we require.

As for the test environment, that's not available to me yet, and since I have no way in really know what's loaded on our main server, it would be very difficult to replicate it.

What exactly would the apache logs show?

[besson3c]

Originally Posted by jon31

Yes, it is very unfortunate that we have to run a virtual dedicated server through someone else. The plan is to get an xserve running in our office soon, but there's no fibre optics in our building yet to handle the bandwidth we require.

As for the test environment, that's not available to me yet, and since I have no way in really know what's loaded on our main server, it would be very difficult to replicate it.

What exactly would the apache logs show?

I don't agree, it would be relatively easy to replicate this problem... Your shopping cart is probably not using any non-standard PHP extensions, and it ought to be relatively easy to move your databases (if you have any) over to a test environment. Your test environment could be any Unix machine, nothing fancy required there.

Personally, I really think you ought to look into Linux or one of the BSDs for your test machine (and also to eventually run on your production machine in your office, if you end up going this route). OS X Client and Server are a PITA to work with for web development, IMHO.


If you had PHP setup to throw up errors in your web browser you could see what was going on. If it didn't, these would be displayed in your Apache logs.

I'm not exactly sure what I'd expect in this case. If it is attempting a connection, the logs would show this and provide some clue as to where the failure was at. If it wasn't, you'd have another indication as to where to focus your energy.


Another suggestion, try looking at your SSL cert contents using Firefox. Check that the SSL cert expiration date is okay if you haven't done so already. Additionally, verify your server's clock is set correctly, this could also cause problems of this nature, I believe.

[jon31]

Interesting that the server clock could affect it, I hadn't thought of that.

If you'd like to see the certificate yourself, it's available here:
https://www.macprovideo.com/cart/

Please let me know if you come across anything suspicious, or if you lag on any of the secure pages.