Ответ 1
Протокол HTTP/1.1 позволяет это, просто в самом странном и запутанном виде. Вам необходимо применить следующие трехступенчатые операции:
- Немедленно (внезапно) закройте соединение, сохраните флаг серверной стороны для сеанса клиента.
- Используйте флаг для обнаружения попытки повторной отправки тех же данных формы, спецификация рекомендует клиенту сделать это автоматически
- Отправьте статус ошибки с помощью перенаправления (например, 302 временно перемещенный)
СЛЕДУЕТ работать, потому что, как указано ниже, ожидается, что клиент будет повторно подключать соединение хотя бы один раз после неожиданно отключенного. При попытке повторной попытки ожидается, что они отправят только заголовки, затем ожидают и наблюдают за сообщением об ошибке и прекращают отправку тела, если он получает его.
http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html
8.2.4 Поведение клиента, если сервер преждевременно закрывает соединение
Если клиент HTTP/1.1 отправляет запрос который включает тело запроса, но который не включает ожидание поле заголовка запроса с Ожидание "100-продолжить", и если клиент напрямую не связан с HTTP/1.1, и если клиент видит, что соединение закрывается до получения какого-либо статуса от сервер, клиент ДОЛЖЕН повторить попытку запрос. Если клиент повторяет этот запросите, МОЖЕТ использовать следующее алгоритм "двоичного экспоненциального отсрочка" быть уверенным в получении надежного Ответ:
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.Если в любой момент состояние ошибки полученный, клиент
- SHOULD NOT continue and - SHOULD close the connection if it has not completed sending the request message.
Gotchas:
- То, о чем спекулят говорят, что нужно делать занавески. Кто знает, какие браузеры НАСТОЯТЕЛЬНО делают в этом случае? Не я. Вам нужно будет выполнить некоторые тесты.
- В спецификации упоминается, что это поведение применяется только "если клиент напрямую не связан с сервером происхождения HTTP/1.1". Это кажется действительно причудливым требованием, которое на практике означает, что вам может понадобиться подделка заголовков ответов сервера, чтобы сделать вид, что вы прокси или сервер HTTP/1.0.
- Некоторые промежуточные протоколы, такие как fast-cgi, не могут активировать ваш script до тех пор, пока запрос не будет завершен. В этом случае вам действительно нужен настоящий сервер сокетов низкого уровня.
- Весь этот процесс грязный и запутанный и может даже не работать. На мой взгляд, вам лучше использовать AJAX. Тем не менее, вы спросили, можно ли это сделать без JS.