Ако наводен 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 одговор. Шифрираните бајти по заглавијата на проксито не се датотеката што се презема.

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

Поврзани статии