The HTTP/1.1 protocol does allow for this, just in a really bizarre and messed up way. You need to apply the following 3 step proceedure:
- Immediately (abruptly) close the connection, store a server-side flag for the client session
- Use the flag to detect an attempt to resend the same form data, the spec recommends the client to do this automatically
- Send an error status with a redirect (like 302 Temporarily Moved)
This SHOULD work because as outlined below the client is expected to retry a connection at least once after being cut off unexpectedly. On the retry attempt(s) it is expected to only send the headers, then wait and watch for an error response and abort sending the body if it gets one.
http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html
8.2.4 Client Behavior if Server Prematurely Closes Connection
If an HTTP/1.1 client sends a request
which includes a request body, but
which does not include an Expect
request-header field with the
"100-continue" expectation, and if the
client is not directly connected to an
HTTP/1.1 origin server, and if the
client sees the connection close
before receiving any status from the
server, the client SHOULD retry the
request. If the client does retry this
request, it MAY use the following
"binary exponential backoff" algorithm
to be assured of obtaining a reliable
response:
1. Initiate a new connection to the server
2. Transmit the request-headers
3. Initialize a variable R to the estimated round-trip time to the
server (e.g., based on the time it took to establish the
connection), or to a constant value of 5 seconds if the round-
trip time is not available.
4. Compute T = R * (2**N), where N is the number of previous
retries of this request.
5. Wait either for an error response from the server, or for T
seconds (whichever comes first)
6. If no error response is received, after T seconds transmit the
body of the request.
7. If client sees that the connection is closed prematurely,
repeat from step 1 until the request is accepted, an error
response is received, or the user becomes impatient and
terminates the retry process.
If at any point an error status is
received, the client
- SHOULD NOT continue and
- SHOULD close the connection if it has not completed sending the
request message.
Gotchas:
- That's what the spec says browswers SHOULD do. Who knows what browsers ACTUALLY do
in this case? Not me. You'll need to run some tests.
- The spec makes a specific mention that this behaviour only applies "if the client is not directly connected to an HTTP/1.1 origin server". That seems a really bizarre requirement which in practice means you may need to fake your server response headers to pretend you're a proxy or HTTP/1.0 server.
- Certain intermediary protocols like fast-cgi may not activate your script until the request is complete. In this event you'll actually need a real low-level socket server.
- This whole process is messy and convoluted and may not even work. You'd be better off using AJAX in my opinion. Still, you did ask if it could be done without JS.