I have been using Uploadify in my PHP application for the last couple months, and I've been trying to track down an elusive bug. I receive emails when fatal errors occur, and they provide me a good amount of details. I've received dozens of them. I have not, however, been able to reproduce the problem myself. Some users (like myself) experience no problem, while others do.
Before I give details of the problem, here is the flow.
User visits edit screen for a page in the CMS I am using.
Record id for the page is put into a form as a hidden value.
User clicks the Uploadify browse button and selects a file (only single file selection is allowed).
User clicks Submit button for my form.
jQuery intercepts the form submit action, triggers Uploadify to start uploading, and returns false for the submit action (manually cancelling the form submit event so that Uploadify can take over).
Uploadify uploads to a custom process script.
Uploadify finishes uploading and triggers the Javascript completion callback.
The Javascript callback calls $('#myForm').submit() to submit the form.
Now that's what SHOULD happen. I've received reports of the upload freezing at 100% and also others where "I/O Error" is displayed.
What's happening is, the form is submitting with the completion callback, but some post parameters present in the form are simply not in the post data. The id for the page, which earlier I said is added to the form as a hidden field, is simply not there in the post data ($_POST)--there is no item for 'id' in the $_POST array. The strange thing is, the post data DOES contain values for some fields. For instance, I have an input of type text called "name" which is for the record name, and it does show up in the post data.
Here is what I've gathered:
This has been happening on Mac OSX 10.5 and 10.6, Windows XP, and Windows 7. I can post exact user agent strings if that helps.
Users must use Flash 10.0.12 or later. We've made it so the form reverts to using a normal "file" field if they have < 10.0.12.
Does anyone have ANY ideas at all what the cause of this could be?
IOError: Client read error (Timeout?)
I got the same error a lot although my server side is python/django. I assumed it was the client timing out, but looking back though the logs for you now there seems to be a coincidence of this ceasing when I changed something in the authentication routines. Is it possible that the server is receiving the file but then refusing to write it to storage?
Also, you aware that several flash clients do not send cookies? You have to work around it by injecting the session keys into uploadify's 'scriptData' variable.
x--------------------------------
Edit. This python/django code starts off the routine to which uploadify submits itself:
# Adobe Flash doesn't always send the cookies, esp. from Apple Mac's.
# So we've told flash to send the session keys via POST. So recreate the
# session now. Also facilitates testing via curl.
cookie_name = settings.SESSION_COOKIE_NAME
if request.member.is_anonymous() and request.POST.has_key(cookie_name):
# Convert posted session keys into a session and fetch session
request.COOKIES[cookie_name] = request.POST[cookie_name]
SessionMiddleware().process_request(request)
# boot anyone who is still anonymous
if request.member.is_anonymous():
response['message'] = "Your session is invalid. Please login."
return HttpResponse(simplejson.dumps(response), mimetype='application/json')
Uploadify might alter the form. Take a look at the html/DOM tree of the form at the time when uploadify has finished and is calling your callback.
Have you tried using Live HTTP Headers in Firefox to see if there is some kind of rewrite happening that is causing the post data to be lost?
Related
I'm expecting a strange error lately.
I'm tracking every error (even soft) from my website and something strange is happening.
1% of user that compile a form sent via post send empty data. Nothing in the post not even the hidden values or the name of the fields. There is also a js validation in this form that could prevent an empty submit.
I'm using Laravel + Nginx. I've track all data but the problem seems not coming from Laravel (I'm tracking POST submission data as first thing in the index.php of laravel and it looks already empty). I've added post data in nginx logs and it looks empty when the error occurs.
It affects mostly mobile devices (of all kind) but also desktop (of all kind).
I've tracked all different form and error come from all forms indistinctly that made a post to this url.
Any idea?
I've been designing a site that is used to collect data, but the person I'm designing for wants some form of redundancy just in case the window is closed or the system shuts down. Is there any way to take data that's been collected and write it to a MYSQL database if the user is disconnected for a certain amount of time, or if they shut the browser window/shut the system down without submitting the data?
The web is stateless and disconnected - so all data will (or rather: should be) persisted between page requests.
I assume you have a web-page generated by PHP that contains a lengthy data-entry form, and you want to save the data in that form in the event the user closes their browser window - the solution is to use a client-script that polls the server with the current data in the form, or at the very least hooks on to the window close event.
Actual implementation is a task left up to the OP.
This can't be done just with a pure HTML page - if the user doesn't submit the form, your server doesn't know what they've typed.
However, you could put some Javascript on the page that made an AJAX call every few seconds (or every few key-stokes or clicks). The idea would be for the JavaScript to invisibly submit the whole form to a PHP page which saved it into a sort of "holding area".
If the user then submitted the form, the holding area could be cleared out, but if they never did, then the data in the holding area would show you where they got to.
The most common techniques to partially prevent this szenario is that web apps work with a heartbeat-function which fires via javascript in a constant interval and sends a request to the server, p.e. to show that the user is still logged on - or, in your case, maybe to submit data already typed into form fields, too.
Think of it as an ajax-powered auto-save-function!
You have to add some javascript to your code for this, but the commonly used javascript libraries, like jquery or mootools, are well documented and offer alot of examples how to do something like this.
I am doing my work in PHP.
I have 3 pages,
A is plain HTML and contains a search field.
B is .php and returns results of the search.
C is also php and allows user to update some details for the displayed results.
When I'm doing Refresh my B page or Go-Back from C to then I
get this message
"To display this page, Firefox must
send information that will repeat any
action (such as a search or order
confirmation) that was performed
earlier."
I saw "When i'm using "POST" method then I get this message, if I'm used GET then
I don't.
Any buddy Explain me ,why???
The GET method should be used to obtain information from a web page.
The POST method should be used to send information to a web page.
The reason it asks you to confirm whether or not to send information again is because it's not always the user's intention to repost a form if they press back. One example is at an online store, you would not want to repost a form to purchase a product twice, otherwise you could be billed for the product twice. This is theoretical of course since someone who makes an online store should ensure that an accidental purchase can't happen.
Also, if you use GET, then all information is appended to the URL of the PHP page. This is a potential security issue, especially if the form contents are private. For such forms, you should be using POST.
A wild guess,
POST is not written in the URL, so you need to resend it, while GET, when you click to return to B, the arguments are still in the URL so you dont need to resend.
Mozilla added this message to warn you from sending the information twice.
Like in the form of registration, you don't want to register twice.
Firefox developers added that warning for POST method. It will warn you for POST in case of back/forward also.
This is an added safeguard for users. Because, most shopping carts/banking portals use POST method for checkout/transaction confirmation (actually I have not seen or developed any web app to use get method for this purpose).
So, Firefox (and most other common browsers) warn you in this scenario (when your are sending POST request indirectly, i.e. using back/forward/refresh button). This prevents the user from multiple checkout.
Another reason to add this warning is, sometimes chekout is time consuming. So, when some time is passed after the original submission, some impatient users think that the browser/server has stopped working. So, they tend to press the refresh button. This warning gives them a good hint.
I think the point is that GET requests should be used to get information without changing anything on the server so if you reload the same information there's no issue. POST requests should be used to change data on the server so when you reload the page that may have undesirable effects.
Firefox should normally allow you to navigate back to your B page from your C page. However if your B page is not in the cache, possibly because it sends a Cache-control: no-store header, then you will get the POSTDATA warning.
On the other hand explicitly reloading page B will always generate a POSTDATA warning.
When you submit data in the POST method, it sends headers to the page you submit to. When you refresh the page or go back, your browser repeats your POST request and Firefox warns you of this.
i have create a form (so it's PHP and HTML hybrid-code). it has ability to send '$_POST'. And when i click it, it work perfectly on sending and displaying input.
But there's something happening when i click Ctrl+R in firefox for represhing the page. I got this confim dialog : "To display this page, Firefox must send information that will repeat any action (such as a search or order confirmation) that was performed earlier"
my question
what is it, (this confirm dialog ?)
what i have to do on my code so it able to suppress this dialog ?
You probably have created an HTML page that contains a <form>. The form is used to send data to the HTTP server (that is, the webserver that hosts your site).
The HTTP protocol defines different request types used to send data to the server and to retrieve data from the server. The most used are GET and POST. You must learn about all this if you want to be anything more than a very bad PHP programmer, which is unfortunately (or fortunately, if you are on the hacker side) very common.
Your problem is that Firefox has arrived on the page you are talking about after sending a POST request. If you reload the page, it has to send the same data again in the form of a POST. Due to the conventions on what a POST request should be used for (usually to modify data on a database), the browser asks the user if he is sure about what he wants to do.
There are mainly two options to circumvent this:
Change the form method to GET; or
Use a redirection after the POST.
To use the first method, you could simply add a method="get" parameter to your form tag:
<form action="senddata.php" method="get"> ... </form>
To use the second method, you simply redirect the user after the POST request, using something like
header("Location: blahblahblah")
The most used pattern is the POST-Redirect, that is, the second method I told you about. There are many security implications on using GET to change data on a database (if you are interested on that, and you should be, as every PHP programmer should, read about XSRF).
Submitting a form (sending a POST request) is commonly used to confirm an order on eCommerce sites. Therefore, submitting it twice would submit the order, twice. Therefore browsers, tend to ask for confirmation that a user wants to send the POST request again.
In order to prevent this, you need to make the refresh do a GET request instead of a POST request. To do this, simply redirect to the same page after processing the form.
header("Location: /path/to/self");
This will make it so when the user hits refresh, it will be sending a GET request instead of a POST request, and it won't prompt for confirmation.
To clairify, it goes like this:
Form gets sent via POST (User clicks on form)
Form gets processed
User gets redirected to the same page (via GET)
User now will be refreshing a GET request instead of a POST request.
I guess whenever your form (php, asps, static html etc) contains post information that may either form field infor or other, is sent to the server via firefox, it displays such a message before sending the data again to server. it serves as a security protection from Mozilla developers. I guess it can be disabled via about:config but it is not recommended to so.
Also it is a normal behaviour. It should be like this and have been like this for a fairly long time in firefox.
You may like to have a look here:
http://forums.mozillazine.org/viewtopic.php?f=38&t=682835&st=0&sk=t&sd=a&hilit=Firefox+must+send
alternatively use GET instead of POST to send your data...
Regards
If the form was submitted successfully, answer with the status code 303:
header('Location: http://www.example.com/', TRUE, 303);
This forces the browser to use a GET request for the resulting page. A reload won’t send any POST data, and no pop up is shown.
I have an application that supplies long list of parameters to a web page, so I have to use POST instead of GET. The problem is that when page gets displayed and user clicks the Back button, Firefox shows up a warning:
To display this page, Firefox must send information that will repeat any action (such as a search or order confirmation) that was performed earlier.
Since application is built in such way that going Back is a quite common operation, this is really annoying to end users.
Basically, I would like to do it the way this page does:
http://www.pikanya.net/testcache/
Enter something, submit, and click Back button. No warning, it just goes back.
Googling I found out that this might be a bug in Firefox 3, but I'd like to somehow get this behavior even after they "fix" it.
I guess it could be doable with some HTTP headers, but which exactly?
See my golden rule of web programming here:
Stop data inserting into a database twice
It says: “Never ever respond with a body to a POST-request. Always do the work, and then respond with a Location: header to redirect to the updated page so that browser requests it with GET”
If browser ever asks user about re-POST, your web app is broken. User should not ever see this question.
One way round it is to redirect the POST to a page which redirects to a GET - see Post/Redirect/Get on wikipedia.
Say your POST is 4K of form data. Presumably your server does something with that data rather than just displaying it once and throwing it away, such as saving it in a database. Keep doing that, or if it's a huge search form create a temporary copy of it in a database that gets purged after a few days or on a LRU basis when a space limit is used. Now create a representation of the data which can be accessed using GET. If it's temporary, generate an ID for it and use that as the URL; if it's a permanent set of data it probably has an ID or something that can be used for the URL. At the worst case, an algorithm like tiny url uses can collapse a big URL to a much smaller one. Redirect the POST to GET the representation of the data.
As a historical note, this technique was established practice in 1995.
One way to avoid that warning/behavior is to do the POST via AJAX, then send the user to another page (or not) separately.
I have been using the Session variable to help in this situation. Here's the method I use that has been working great for me for years:
//If there's something in the POST, move it to the session and then redirect right back to where we are
if ($_POST) {
$_SESSION['POST']=$_POST;
redirect($_SERVER["REQUEST_URI"]);
}
//If there's something in the SESSION POST, move it back to the POST and clear the SESSION POST
if ($_SESSION['POST']) {
$_POST=$_SESSION['POST'];
unset($_SESSION['POST']);
}
Technically you don't even need to put it back into a variable called $_POST. But it helps me in keeping track of what data has come from where.
I have an application that supplies long list of parameters to a web page, so I have to use POST instead of GET. The problem is that when page gets displayed and user clicks the Back button, Firefox shows up a warning:
Your reasoning is wrong. If the request is without side effects, it should be GET. If it has side effects, it should be POST. The choice should not be based on the number of parameters you need to pass.
As another solution you may stop to use redirecting at all.
You may process and render the processing result at once with no POST confirmation alert. You should just manipulate the browser history object:
history.replaceState("", "", "/the/result/page")
See full or short answers