Se un suposto PDF ou folla de cálculo comeza con HTTP/1.1 200 OK, o descargador gardou unha resposta en bruto en lugar do ficheiro. Esta resposta esquemática só contén catro bytes de contido:

HTTP/1.1 200 OK
Transfer-Encoding: chunked

4
DATA
0

O ficheiro é DATA. A liña de estado, as cabeceiras, o marcador de tamaño e a estrutura de terminación pertencen a HTTP. Eliminar un número fixo de bytes non é seguro porque as lonxitudes das cabeceiras varían. Copiar todo o que segue a primeira liña en branco aínda deixa o enmarcado de fragmentos, e as respostas informativas poden preceder a resposta final.

Para unha descarga normal, substitúa a copia de socket en bruto a ficheiro pola interface de corpo de resposta do cliente HTTP. Configure o seu proxy, valide o estado final e transmita o corpo a unha saída temporal. O cliente xestiona o enmarcado da mensaxe: os corpos delimitados por lonxitude, por fragmentos e por conexión requiren unha análise distinta.

A codificación do contido é outra capa. Decida se necesita bytes descodificados do ficheiro ou contido en bruto solicitado explicitamente, segundo o comportamento documentado do cliente. Os bytes comprimidos non son automaticamente unha corrupción do proxy.

Se a aplicación debe conservar código a nivel de socket, asume todas esas regras de análise ademais do manexo de lectura e escritura. Escriba só o número de bytes que realmente devolve unha lectura, non a capacidade do búfer, e xestione as escrituras parciais. Se non, o contido obsoleto do búfer pode corromper mesmo un corpo extraído correctamente.

HTTPS require máis que despoxar unha resposta CONNECT: tras establecer o túnel correctamente, estableza TLS de destino e despois analice a resposta HTTP interna. Os bytes cifrados que seguen as cabeceiras do proxy non son o ficheiro descargable.

Deixe a saída fallida ou incompleta cun nome temporal. Publíquea só cando o traspaso e as comprobacións do ficheiro teñan éxito; un ficheiro non baleiro non demostra unha descarga completa.

Artigos relacionados