Forum Moderators: open
Having not been able to find the cause of this, we firstly tried the application on three different servers (all Linux) at different ISPs and the same problems occurred. We then completely re-wrote the application using an embedded Flash form rather than conventional HTML forms as in the original. Exactly the same problems occurred with the data posted from Flash not being received by the server (although the request itself reached the server and the script in question was activated).
After further investigation of the server logs we have now discovered the cause of the problem: namely that the POST requests are getting changed to GET requests! This happens only intermittently and under specific circumstances which we cannot determine. It happens for each of IE5, IE6 and IE7. The problem is not specific to a particular user location as it has been experienced by users from several quite distinct organisations and sites. Since both versions of the application, HTML and Flash are explicitly sending the data via POST, the changing of POST to GET must be occuring either within the browser or by something at the server end prior to the data reaching the script.
As I have been able to find no other occurrences of this problem reported on the web so far, it may be specific to the data that is getting posted. Briefly, the data is around 1K in length, and consists of sequences of comma-separated numbers, textual comments, some data markers surrounded by angled brackets, a few $ signs, a few forward slashes and a few @ signs. The problem occurs when this data is POSTed either as a single variable (in the Flash version of the application) or as a number of distinct variables in the original version.
Given that this problem arose very shortly after the recent IE updates and since absolutely nothing has changed from previously when it was working unproblematically (and had done so for six years), we suspect either the IE update as the principal candidate for the cause of this (though if by chance our ISPs have installed Apache updates over this period, that is also a candidate).
Any further news about similar problems or suggestions as to causes would be greatly appreciated.
As for Firefox, unfortunately we don't know. We can't reproduce the phenomenon ourselves even in IE. We just know it's happening for our users. Presumably there is some particular configuration of software (or perhaps even data that is typed in) which causes the problem - though what, we have no idea.
OK simple questions, does the page that this form is on validate? Run it through the W3C validator. It could be something is broken on the page but is not changing the page appearance, and it's breaking your form method specification. As you know, if you don't set method="post" it will default to get.
Another option is if you can entice one cooperative user that it does happen repeatedly on into testing pages for you, create a simplified sample page and throw them at it. See if you can reproduce it on other pages.
Unfortunately we can't the HTML version of the app via WC3 as each page of the questionnaire is generated from a Perl script and only the error page output from the script gets validated.
In the Flash version, the POST method is defined in the Flash application so we know there's nothing about the form that's breaking the METHOD specification. Aside from this, we use the same Flash method of data submission with more than 100 other applications so we know that's okay. This is why it has to be something to do with the data that's submitted.
Unfortunately, we can't really get users to do the testing for us, as our clients are understandably having a fit about the service not working. Furthermore, the phenomenon is so variable that it's not simply a question of one user having problems and others not. Rather it seems to be that certain specific data submitted (both numerical and/or textual) triggers the problem. So it's more or less impossible to know how to reproduce as we never capture the data that triggers it!
From: Hypertext Transfer Protocol -- HTTP/1.1 [w3.org]
10.3.2 301 Moved PermanentlyNote: When automatically redirecting a POST request after
receiving a 301 status code, some existing HTTP/1.0 user agents
will erroneously change it into a GET request.
In short, if a POST is permanently redirected for any reason, an HTTP/1.0 client may change the method to GET. Since modern browsers use HTTP/1.1, this action would have to be as a result of (old, outdated) intervening network equipment.
Jim
John
Unfortunately we can't the HTML version of the app via WC3 as each page of the questionnaire is generated from a Perl script.....
What you can do is get on this page, save the page or view source and save the source as a plain HTML file, then upload it to your server or use the W3C upload service to validate. It's how I test all my dynamic pages and various states if I can't do it via direct URL.
