单击浏览器上的“停止”按钮会怎样？

Question

Let's say I click a button on a web page to initiate a submit request. Then I suddenly realize that some data I have provided is wrong and that if it gets submitted, then I will face unwanted consequences (something like a shopping request where I may be forced to pay up for this incorrect request).

So I frantically click the Stop button not just once but many times (just in case).

What happens in such a scenario? Does the browser just cancel the request without informing the server? If in case it does inform the server, does the server just kill the process or does it also do some rolling back of all actions done as part of this request?

I code in Java. Does Java have any special feature that we can use to detect STOP requests and rollback whatever we did as part of this transaction?

Answer 1

A Web Page load from a browser is usually a 4 step process (not considering redirections):

1. Browser sends HTTP Request, when the Server is available
2. Server executes code (for dynamic pages)
3. Server sends the HTTP Response (usually HTML)
4. Browser renders HTML, and asks for other files (images, css, ...)

The browser reaction to "Stop" depends on the step your request is at that time:

• If your server is slow or overloaded, and you hit "Stop" during step 1, nothing happens. The browser doesn't send the request.
• Most of the times, however, "Stop" will be hit on steps 2, 3 and 4, and in those steps your code is already executed, the browser simply stops waiting for the response (2), or receiving the response (3), or rendering the response (4).

The HTTP call itself is always a 2 steps action (Request/Response), and there is no automatic way to rollback the execution from the client

Answer 2

Since this question may attract attention for people not using Java, I thought I would mention PHPs behavior in regard to this question, since it is very surprising.

PHP internally maintains a status of the connection to the client. The possible values are NORMAL, ABORTED and TIMEOUT. While the connection status is NORMAL, life is good and the script will continue to execute as expected.

If the user clicks the Stop button in their browser, the connection is typically closed by the client and the status changes to ABORTED. A change of status to ABORTED will immediately end execution of the running script. As an aside, the same thing happens when the status changes to TIMEOUT (PHPs setting for the allowed run-time of scripts is exceeded).

This behavior may be useful in certain circumstances, but there are others where it could be problematic. It seems that it should be safe to abort at any time during a proper GET request; however, aborting in the middle of a request that makes a change on the server could lead to only partially completed changes.

Check out the PHP manual's entry on Connection Handling to see how to avoid complications resulting from this behavior:

http://www.php.net/manual/en/features.connection-handling.php

Answer 3

Generally speaking, the server will not know that you've hit stop, and the server-side process will complete. At the point that the server tries to send the response data back to the client, you may see an error because the connection was closed, but equally you may not. What you won't get is the server thread being suddenly interrupted.

You can use various elaborate mechanisms to mitigate this, like having the send send frequent ajax calls to the server that say "still waiting", and have the server perform its processing in a new thread which checks these calls, but that doesn't solve the problem completely.

Answer 4

The client will immediately stop transmitting data and close its connection. 9 out of 10 times your request will already have got through (perhaps due to OS buffers being "flushed" to the server). No extra information is sent to the server informing it that you stopped your request.

Answer 5

Your submit in important scenarios should have two stages. Verify and submit. If the final submit goes though, you commit any tranactions. I cant think of any other way really to avoid that situation, other than allowing your user to undo his actions after a commit. for example The order example, after the order is done to allow your customers to change their mind and canel the order if it has not been shipped yet. Of course its extra code you need to write to suuport that.