Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>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:</p> <ol> <li>Immediately (abruptly) close the connection, store a server-side flag for the client session</li> <li>Use the flag to detect an attempt to resend the same form data, the spec recommends the client to do this automatically</li> <li>Send an error status with a redirect (like 302 Temporarily Moved)</li> </ol> <p>This <em>SHOULD</em> 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.</p> <p><a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html" rel="noreferrer">http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html</a></p> <blockquote> <p>8.2.4 Client Behavior if Server Prematurely Closes Connection</p> <p>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:</p> <pre><code> 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. </code></pre> <p>If at any point an error status is received, the client</p> <pre><code> - SHOULD NOT continue and - SHOULD close the connection if it has not completed sending the request message. </code></pre> </blockquote> <p>Gotchas:</p> <ol> <li>That's what the spec says browswers <em>SHOULD</em> do. Who knows what browsers <em>ACTUALLY</em> do in this case? Not me. You'll need to run some tests.</li> <li>The spec makes a specific mention that this behaviour only applies "<em>if the client is not directly connected to an HTTP/1.1 origin server</em>". 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.</li> <li>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.</li> <li>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.</li> </ol>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload