SAIX Proxy Breaking my PHP Form?

D

Darkling

Active Member
Joined
Sep 5, 2005
Messages
65
Reaction score
0
Location
St Francis Bay
Hi all

I am submitting from a form to another php page which is supposed to process it. The problem is that the $_POST is often empty when I try to read it.

This is a simplified version of the form for testing:
PHP: 
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">

<head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
    <title>Order Form</title>
</head>


<body>
    <form id="mailorder" name="mailorder" action="mailordertest.php" method="post">
        <input type="hidden" name="A212-M" value="1" /> 
        <input type="hidden" name="A212-XXXL" value="2" /> 
        <input type="hidden" name="A212-XXL" value="3" /> 
        <input type="hidden" name="A212-XL" value="4" /> 

        <input type="submit" value="Confirm Order">
    </form>
</body>
</html>

And this is the processing page:

PHP: 
<?php
    session_start();
    error_reporting(E_ALL);

    print_r($_POST);
?>

This will usually output nothing but Array (), but sometimes the data will come through first time. When the $_POST is empty, I can hit Back and then resubmit and after a few tries, it will work.

I have inspected the whole shebang with FireBug and it seems that the $_POST is getting cleared because the processing page does a 302 redirect back to itself (that obviously uses a GET, and so the POST data is discarded).

I have googled this to death, but none of the answers I have found have been any help. The following are NOT the problem: 1. post_max_size is set to 8M (not MB) 2. There is no CONTENT_TYPE issue

Other PHP apps are working fine on the server (Wordpress etc), and I am using PHP 5.2.9.

I am totally stumped on this one - so thanks for ANY ideas and help!

Big important note: I have only ever seen this happen when I am connected via SAIX. As soon as I go to an IS connection, everything works nicely.
 
My initial reaction reading this is "cache problem". Not entirely sure what you'd do, but in ASP there's a Cache-Control and Response.Expires setting that you can set to tell the world out there that the page you're working with shouldn't be cached and expired immediately because several applications caches content out there, of which are:

Your PC itself
Your browser
Your router (if you have a stand-alone server acting as your router)
Your web-server (IIS for example) <-- this could be your local machine or remote server
Your transparent proxy (like which SAIX uses, IS uses them too, but have proved to know what dynamic content is and how to handle it, unlike our technology stinted Telkom guys)

Above combination caches various things, and it's important to get the page to tell them all to shove it when loading. The 302 you're getting might even be a locally cached issue (as I've seen sometimes, a browser will cache a form submission, especially when using back/forward buttons)
 
Hey AcidRaZor, I have tried as many cache-control options in the header as I have been able to find on the net with no luck.

I have also had this problem when submitting with curl, so I don't believe its a local caching error.
 
@Darklink, as a test submit the form on HTTPS port - which can't be cached, and see if that helps. If it does, then it could be a transparent proxy issue with your ISP?
 
Hi SoftDux. Im already 99% sure its a problem with the SAIX proxy. The reason it breaks is because something (SAIX) is slipping in a 302 redirect, but back to the form I am already submitting to. Since it is a redirect, the page is fetched using a GET and therefore loses all my $_POST variables.
My problem though, is that everything else works find on my server, including a few dozen Wordpress installs and various other PHP goodies. It is only the stuff I am creating that is having this problem.
The settings are exactly the same for all accounts on my server, so I have ruled out server settings being the problem.

I need to know - why does Wordpress work, not mine??? Thats whats really been driving me nuts.



Edit: I should note that I actually found someone else who has this exact same problem, with a different hosting company, except he is submitting to a downloaded php mailer script. His also breaks when he tries to submit his form, but again, going back and re-submitting the form a few times works. He is also on SAIX. So whatever the problem is, its not just me.
 
Last edited:
have you tried CURL, or REQUEST instead of POST? Why does Wordpress work? That's a good question, I don't know the underlying code for this process, but the developers of those kinds of websites (i.e. WordPress / Joomla / SMF / vBulletin / etc) often get these kind of "complaints" from users, so they had to work some sort of magic into the code.

What I do know, is that the transparent proxies @ IS & SAIX have a few different IP's, so it "floats", which also cause problems. Is your code using IP checks?
 
He mentioned already trying curl. What I'd suggest you do is submit the form with a unique variable within the form element. So a hidden <input type=hidden> with some random value in it to help with creating a unique page on load each time. Include that with what you tried in terms of caching. It can't be saix IMO. Has to be your code. If all else fails do a ?unique=spmethingunique to the form you're submitting.

From what I read you didn't try submitting to https either. So try that too as it won't be cached. If THAT doesn't work it's your broswer caching it.
 
AcidRaZor said:
He mentioned already trying curl. What I'd suggest you do is submit the form with a unique variable within the form element. So a hidden <input type=hidden> with some random value in it to help with creating a unique page on load each time. Include that with what you tried in terms of caching. It can't be saix IMO. Has to be your code. If all else fails do a ?unique=spmethingunique to the form you're submitting.

From what I read you didn't try submitting to https either. So try that too as it won't be cached. If THAT doesn't work it's your broswer caching it.
Click to expand...

I have already tried the hidden random variable, but that didn't work eithe :cry:

The example above is a simple one, but I have used even simpler, trying to debug this - I don't think its my code, and I have gone through the Wordpress code looking for anything which could explain why theirs works and mine doesn't.

Ill try the https thing, but I will bet it will work fine. But changing the whole thing to https isnt really an option for this.
 
Darkling said:
I have already tried the hidden random variable, but that didn't work eithe :cry:

The example above is a simple one, but I have used even simpler, trying to debug this - I don't think its my code, and I have gone through the Wordpress code looking for anything which could explain why theirs works and mine doesn't.

Ill try the https thing, but I will bet it will work fine. But changing the whole thing to https isnt really an option for this.
Click to expand...

Trust me on this. If wordpress works fine. EVERY OTHER SITE ON THE INTERNET works fine. Then it's your code :)
 
AcidRaZor: My code is in the first post, any idea which part of it is wrong?

StackOverflow tells me the code is fine, and it works 100% of the time when I am connected via IS - only breaking when I am on a SAIX connection.

Every other site on the internet doesn't really work fine either - I have experienced weird forum behavior in the past on some international sites, which in hindsight are very similar to the problem I am having ie. empty $_POST variables.
 
Install the Live Headers add-on for Firefox: https://addons.mozilla.org/en-US/firefox/addon/3829

Then you can find out what is issuing the 302 redirect, which will be the cause of the problem. If it truely is the post processing php page that is doing the redirect, there must be something in there, or perhaps some kind of htaccess or server setup causing it. It's highly unlikely to be a SAIX issue.
 
Last edited:
Denouncer said:
Install the Live Headers add-on for Firefox: https://addons.mozilla.org/en-US/firefox/addon/3829

Then you can find out what is issuing the 302 redirect, which will be the cause of the problem. If it truely is the post processing php page that is doing the redirect, there must be something in there, or perhaps some kind of htaccess or server setup causing it. It's highly unlikely to be a SAIX issue.
Click to expand...

I tend to agree that it can't be a SAIX issue, otherwise I would have had these problems as well (as would most of this forum, and you know how we can bitch and moan about Telkom ;) )

That's the only reason why I said it has to be your code. It's something small you're missing. Your code might work as intended, but there might be something that's not doing it's job properly or interfering with the process.

Have you tried testing this from a different machine?
 
Thanks for that Denouncer, I have installed Liveheaders, which is how I know about the 302 redirect breaking the POST. But it gives no further useful information.

This is ONLY broken on SAIX. It works 100% of the time through IS, Vodacom and MTN. Tested on multiple connections, with multiple browsers.
 
Darkling said:
Thanks for that Denouncer, I have installed Liveheaders, which is how I know about the 302 redirect breaking the POST. But it gives no further useful information.

This is ONLY broken on SAIX. It works 100% of the time through IS, Vodacom and MTN. Tested on multiple connections, with multiple browsers.
Click to expand...

On multiple machines?
 
Hmmm, well I can't help with fixing the problem, but I can attest to the fact that this DOES happen on SAIX. My parents use Hotmail a lot, via their crappy web interface. Whenever we're using SAIX bandwidth, the messages often dont send, due to a lack of content. We discovered that going back and resubmitting the mail (often a few times) does fix the issue. Switch to IS data and it's fine.

(Tried on multiple machines, browsers)
 
Yep, a few dozen different machines, operating systems and browsers. My app was completely rolled out before we found this problem, and the log file tells me it only happened to people who were connected via SAIX.
 
Have you checked your server to see if mod_expires is set into the past which would automatically expire dynamic PHP pages?
 
You must log in or register to reply here.
Back
Top
Sign up to the MyBroadband newsletter
X