Када преузета датотека почиње HTTP статусном линијом

Ако наводни PDF или табела почиње са HTTP/1.1 200 OK, преузимач је сачувао сирови одговор уместо датотеке. Овај шематски одговор садржи само четири бајта садржаја:

HTTP/1.1 200 OK
Transfer-Encoding: chunked

4
DATA
0

Датотека је DATA. Статусна линија, заглавља, ознака величине и завршна структура припадају HTTP-у. Уклањање фиксног броја бајтова није безбедно јер се дужине заглавља разликују. Копирање свега после првог празног реда и даље оставља оквир делова, а информативни одговори могу претходити коначном одговору.

За нормално преузимање замените копирање из сирове утичнице у датотеку интерфејсом за тело одговора HTTP клијента. Подесите његов прокси, проверите коначни статус и проследите тело у привремени излаз. Клијент се бави оквиром поруке: тела ограничена дужином, по деловима (chunked) и ограничена везом захтевају различито рашчлањивање.

Кодирање садржаја је још један слој. Одлучите да ли вам требају декодирани бајтови датотеке или изричито захтеван сирови садржај, ослањајући се на документовано понашање клијента. Компресовани бајтови нису аутоматски оштећење проксија.

Ако апликација мора да задржи код на нивоу утичнице, она сноси одговорност за сва та правила рашчлањивања као и за руковање читањем и писањем. Уписујте само број бајтова које је читање стварно вратило, а не капацитет бафера, и рукујте делимичним уписима. У супротном застарели садржај бафера може оштетити чак и исправно извучено тело.

HTTPS захтева више од уклањања CONNECT одговора: после успешног успостављања тунела успоставите TLS ка одредишту и затим рашчланите унутрашњи HTTP одговор. Шифровани бајтови након заглавља проксија нису датотека која се преузима.

Неуспешан или непотпуни излаз оставите под привременим именом. Објавите га тек након што пренос и провере датотеке успеју; датотека која није празна не доказује потпуно преузимање.