Бінарны файл павінен дасягаць HTTP-кліента як байты. Чытанне яго тэкставым чытачом і паўторнае кадаванне атрыманага радка ў ASCII можа замяніць значэнні яшчэ да таго, як проксі што-небудзь атрымае. Праца невялікага тэкставага ўзору не робіць гэты шлях бяспечным для выявы, архіва або дакумента.

У існуючым шляху запампоўкі .NET заменіце гэтае пераўтварэнне бінарнай крыніцай цела:

using var file = File.OpenRead(path);
using var content = new StreamContent(file);

Перадайце змесціва праз наладжаны ў праграме HTTP-загрузку; фрагмент устанаўлівае крыніцу цела, а існуючы кліент па-ранейшаму валодае метадам, пунктам прызначэння, проксі і кіраваннем тэрмінам жыцця.

Выдаліце любы Content-Length, разлічаны па колькасці сімвалаў старога радка. Гэтае поле вымярае актэты. Дазвольце HTTP-бібліятэцы будаваць фраймінг з прадстаўлення цела замест спалучэння колькасці сімвалаў з буферам у іншай кадоўцы.

Для наўмыснай тэкставай запампоўкі выберыце кадоўку яўна і вывядзіце патрэбную даўжыню з байтоў, якія адпраўляюцца. Гэтае рашэнне аб тэкставым фармаце не павінна прымяняцца да адвольных файлаў.

Параўнайце перададзены файл з давераным чаканым значэннем. Поспех HTTP пацвярджае, што аперацыя запампоўкі завяршылася на гэтым узроўні; ён не можа паказаць, што папярэдняе тэкставае пераўтварэнне захавала зыходныя байты.

Падобныя артыкулы