Hello,

In Firefox, I prepared a long text in a page, but when i sent it, the server returned the error. I pressed "back", but then the page was reloaded and the form cleaned. I pressed "forward" again, so the form POST request is repeated, but the error continues.

How can i see the POST request variables sent to the server? I tried to use the dev tools it has, but could not find it. Is it possible to do, without closing the browser, which would discard the data for that request, i think.

F12 > Network > right-click on request and go into Copy menu - should have "Copy POST Data" option, or if not "Copy as cURL" should include a version of it.

Left-clicking on the request may bring up a panel with a "Params" tab, but that'll probably be more effort to get at your data.

(If you don't see the request in the network tab, F5 on the POSTed page should resend it with those params, and then display it.)

1 members found this post helpful.

Thank you for the quick reply, boughtonp. It seems that Firefox is not repeating the POST request, as i thought it would be. I found no POST request. Before i asked here, i did part of what you said.

Is there a way the page can discard my post data, and redirect to a page where there is no data sent, so reloading will be only normal direct or GET requests, at most?

I opened a new tab, tested with a form. I could see the POST data, as i wanted. But coming back to the X error page, no use.

For the test form in the site, for which i tested and said that i could see the POST request in the network thing. If i press "back" and then "forward", Firefox shows a "document expired" error, giving a try again button. If i press it, Firefox asks if i want to send data again - and there is the key for getting the data with the dev tool.

I do not understand what the other page does to discard the data, in a way Firefox does not care about it too. Do you?

You can also intercept traffic with a proxy: Burp Suite or OWASP ZAP and see all POSTs and GETs. Little more set up than the browser dev tools but still pretty easy. Recommend the free version of Burp suite as it is more intuitive than ZAP if you have never used a web proxy tool before.

Use of a proxy tool will only work if you are POSTing to a server though - won't work for DOM (local) traffic.

2 members found this post helpful.

What was the error?
Has the script on the server ever worked?

The server/webapp could cause that, yes - it's the difference between a 302 and a 307 response.

For 307 (Temporary Redirect) the browser must use the same request method (i.e. repeat the POST to the new Location), whereas with 302 (Found) the browser will do a GET instead.

The latter is useful on successful POSTs, to allow the user to refresh a status page without repeating the request, but if there was a server error then a redirect should not occur (the status should be 5xx, indicating that the user can F5 to re-POST the request later when the server issue is resolved), but it's always possible the software was written by developers that don't know what they're doing.

That's the reason I almost always either have a notepad open when writing more than a line of text and/or will hit Ctrl-A,X,V before submitting the form.

What ever the specific technical reasoning is here: this has happened to me maybe a dozen times, then I installed an addon that backs up all form entries. No more frustration. Since then, it's always one of the first things I do on a new install.

1 members found this post helpful.

I will try Owasp Zap first. It even has a help group (although i would try here first, as it is almost always of great help. (:

I search around a bit, and I am surprised it is not in Debian repository (right?). It has a tar.gz package. I wonder if it will integrate well in the system, as a normal .deb package would.

It is a group game server. I was making a move in the game, and writing a comment. But while i wrote my comment, someone else did the move i intended to do. So, the server said "this move is already done". If the form was kept loaded when i pressed back, from this screen, i would not mind - i would just put my text in another move. But sometimes this happens (i am talking about different sites! Not a changing behaviour of specific pages), and other times it does not. I do not know what makes this one way or the other.

The script in the server works normally. Except that sometimes we find some errors to be fixed. (:

I see. With Owasp Zap i will easily see what the server is returning, right? I am suspecting of a 302 response, although, as you can imagine, this is not what i wanted earlier.

In the situation that occurred, the POST is successful, but the game changed the state between the time i opened it, and sent the next move. So, i am not confident that this should be called a server error. Should it? I want to repost the data, though (me, the slower player with precious data). What you think?

Yes, i had this idea too, before. In my computer, i use 6 virtual desktops. In most of them, i always have a terminal and a "notepad" (Mate's pluma, actually) open. I never save anything, but i copy/paste/use as predefined texts source/etc. a lot in them. For advanced edits, i open one of my terminals (usually in RAM, /dev/shm) with "vim t" for anything that does not need to spend disk writes. A bit sick, i think. But i barely care about it... haha

Ahh. I’ve misunderstood the problem then...and have nothing to add to the other advice posted. Sorry.

Nope, in that case the relevant response might be 409 (Conflict) which is a 4xx request error not a 5xx server error, and suggests you may be able to take action to remedy the situation (i.e. send a new move).

A well-written application would indicate what the conflict was (another player moved) and give you the opportunity to adjust your move as well as keep/clear what you'd written - I would expect that to happen from the same screen, not necessarily requiring use of the back button; but this all depends on specifics of the interface and way the game works.

It may be that clearing the text after an error is a deliberate choice, but it's perhaps more likely that the status of the request isn't fully checked and clearing that should only occur on success also happens on failure, and it's the nature of how the interface is built that stops the back button from being a workaround.
(Codewise, this sort of thing that can be as simple as a 1-2 line change to fix, but can sometimes require significant refactoring of whole sections.)


On the proxy front, be aware that they will probably default to capturing all traffic - not just for the tab you're interested in - and you'll need to either keep it running or configure it on and off when needed - you might prefer to simply keep the Network Monitor tab open whilst playing - with persist logs enabled and disable cache disabled - and that should show you the requests you're interested in, and is likely easier than configuring proxy settings.

1 members found this post helpful.