SAIX Proxy Breaking my PHP Form?

My server doesn't use mod_expires. But thanks for making me check

Think it might be depreciated in the newer versions of Apache, sorry about that. However, the last thing you could try is to get your server to respond with an expiry in the past (making it expired immediately and should instruct the transparent proxy to get a newer version). This is the same method on saving on bandwidth/making the site load quicker by giving the images on the site an expiry of 1 month, where the browser/transparent proxy would only compare file sizes and your server would normally respond with a "not modified" header.

Did you try different load of test data? Could be the proxy is seeing the same size for the page coming through and caching like that? I've never, in the past 10 years using SAIX and programming for the web, seen this problem. (And I've used hotmail etc like you mentioned)
 
More info:

Here is a curl command I use to test
Code:
curl -d "A=1" -d "B=2" -d "C=3" -i [url]http://www.whitestar.za.net/mailordertest.php[/url]

HTML:
HTTP/1.1 302 Redirect
Date: Tue, 09 Feb 2010 16:03:33 GMT
Content-Length: 284
Content-Type: text/html
Server: NetCache appliance (NetApp/6.1.1D8)
Connection: close
Location: http://www.whitestar.za.net:80/mailordertest.php

<HTML>
<HEAD><TITLE>302 Moved Temporarily</TITLE></HEAD>
<BODY>
<H1>Moved Temporarily<H1>
<H4>
You are being redirected to a new location because:<P>
[code=BYPASSED_URL] The client request was forwarded directly to the origin server. No action is required.
</H4>
<HR>
</BODY>
</HTML>

Please note the server line in there: Server: NetCache appliance (NetApp/6.1.1D8)
 
Think it might be depreciated in the newer versions of Apache, sorry about that. However, the last thing you could try is to get your server to respond with an expiry in the past (making it expired immediately and should instruct the transparent proxy to get a newer version). This is the same method on saving on bandwidth/making the site load quicker by giving the images on the site an expiry of 1 month, where the browser/transparent proxy would only compare file sizes and your server would normally respond with a "not modified" header.

Did you try different load of test data? Could be the proxy is seeing the same size for the page coming through and caching like that? I've never, in the past 10 years using SAIX and programming for the web, seen this problem. (And I've used hotmail etc like you mentioned)

I have generated random numbers in the form and submitted those along with the actual data with no effect.
Also, when inspecting my logs, the cache server makes no requests at all except for the second GET after the 302. Ie. My server isn't hit AT ALL until the 302 is sent back to the browser and the browser obeys the 302 and does a GET.
 
I'm not going crazy!

Thanks for the posts - I have EXACTLY the same issue, and I thought I was going mad. I use Drupal as a CMS and none of those forms seem to act up. I wrote a very small and simple mailer script for a designer in our office & its been such a problem. About 1 in 3 Posts get variables and the other 2 posts get lost, no variables.
On someone's advice, I installed the Live Headers add-on for Firefox, and voila - I see the 302 redirect happening. I see the NetCache appliance (NetApp/6.1.1D8) line - that's actually how I found this thread - by googling the NetCache line.
As a really-really-really last resort - I tried taking out all reference to the word mail in my email post URL - it seems to have worked, although its still early days. I've only submitted 3 times and someone from the office has submitted as many (All worked). On the other hand, the script with the keyword 'mail' somewhere in the URL, failed today 2 out of the 3 times I posted it.
 
You never answered, when the POST gets forwarded by the transparent proxy, do the parameters come through as GET parameters, or not at all? Ie. are they available via $_REQUEST? If so, you could simply account for the SAIX issue by checking if $_POST is empty, and then falling back to to $_REQUEST?

Local ISPs do have some bizarre policies on their transparent proxies, though by definition, you are never supposed to cache a POST. We had an issue a couple of years ago where IS were caching EVERYTHING in a form submission result, including cookies in the header. Unfortunately the form was a login page, and users logging in would get previous login cookies, and enter the system as someone else, no matter how many random parameters, meta tags or anti caching headers we employed.
 
For me, URL variables are preserved, but $_POST variables don't come through on the URL, so they're not available in $_GET scope, the request scope is also empty of any form vars. The only way I can tell that the form is posted, is by having a $_GET variable on the form action. So a get, instead of a post would work, but I have a massive form and I'm not happy with sending it via the get method.
Your login issue sounds like a complete nightmare!
 
Top
Sign up to the MyBroadband newsletter
X