Когато изтегленият файл започва с ред за състояние на HTTP

Ако предполагаем PDF или електронна таблица започва с HTTP/1.1 200 OK, изтеглящият е запазил суров отговор вместо файла. Този схематичен отговор съдържа само четири байта съдържание:

HTTP/1.1 200 OK
Transfer-Encoding: chunked

4
DATA
0

Файлът е DATA. Редът за състояние, заглавките, маркерът за размер и терминиращата структура принадлежат на HTTP. Премахването на фиксиран брой байтове е опасно, защото дължините на заглавките варират. Копирането на всичко след първия празен ред все още оставя рамкиране на части, а информационните отговори могат да предхождат крайния отговор.

За нормално изтегляне заменете копирането от суров сокет към файл с интерфейса за тяло на отговора на HTTP клиента. Конфигурирайте неговото прокси, валидирайте крайния статус и предайте тялото към временен изход. Клиентът се грижи за рамкирането на съобщението: телата, ограничени по дължина, на части и по връзка, изискват различен анализ.

Кодирането на съдържанието е допълнителен слой. Решете дали ви трябват декодирани байтове на файла, или изрично поискано сурово съдържание, според документираното поведение на клиента. Компресираните байтове не са автоматично прокси повреда.

Ако приложението трябва да запази код на ниво сокет, то притежава всички тези правила за анализ, както и обработката на четене и запис. Записвайте само броя байтове, действително върнати от четене, а не капацитета на буфера, и обработвайте частичните записи. Иначе остарялото съдържание на буфера може да повреди дори правилно извлечено тяло.

HTTPS изисква повече от премахване на CONNECT отговор: след успешно установяване на тунела установете TLS до дестинацията и след това анализирайте вътрешния HTTP отговор. Криптираните байтове след заглавките на проксито не са файлът за изтегляне.

Оставяйте неуспешния или непълен изход под временно име. Публикувайте го само след като трансферът и проверките на файла успеят; непразен файл не доказва пълно изтегляне.