Перенаправление до загрузки POST завершено

Ответ 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.

Ответ 2

Посмотрите на билет django # 10850 - "Невозможно остановить большой поток загрузки файлов" . Не решает проблему, но по крайней мере это должно помочь вам понять ее.

Ответ 3

• используйте расширение загрузки PCEL, если вы используете apache
• создайте файл для опроса meta через Ajax и верните trueor false на основе вашего условия, вы также можете получить файл temp_name и проверить метатеку 1kb.
• вызов ajax необходимо связать с функцией, которая использует заголовки метаобновления HTML для перенаправления или останова до завершения загрузки.

Ознакомьтесь с примерами uploadprogress.