Спампоўка праз Java-проксі, калі getContentLengthLong вяртае -1

Апрацоўвайце невядомы Content-Length пры спампоўцы праз проксі, не ўспрымаючы адсутнасць метаданых памеру як пусты адказ.

getContentLengthLong() == -1 азначае, што ў даступных метаданых няма вядомай даўжыні змесціва. Працягвайце чытанне патоку і паказвайце атрыманыя байты або нявызначаны прагрэс; не лічыце гэта пустым адказам і не выдзяляйце буфер адмоўнага памеру.

long expected = connection.getContentLengthLong();
long received = 0;
byte[] buffer = new byte[8192];
try (InputStream input = connection.getInputStream()) {
    int count;
    while ((count = input.read(buffer)) != -1) {
        output.write(buffer, 0, count);
        received += count;
    }
}

Злучэнне ўжо наладжана, і output належыць выклікальніку. Захоўвайце тайм-аўты злучэння і чытання, а таксама любы ліміт памеру праграмы вакол гэтага цыкла. Памылка ўводу-вываду — гэта няўдалая спампоўка, а не паспяховае завяршэнне з меншай колькасцю байтаў.

Параўноўвайце даўжыні на адным узроўні. Chunked-кадаванне HTTP/1.1 можа замяніць Content-Length і дэкадуецца рэалізацыяй HTTP. Проксі можа перафармаваць яго. Дэкампрэсія таксама можа зрабіць дэкадаваную колькасць байтаў праграмы адрознай ад закадаванага Content-Length.

Калі прысутнічаюць і Transfer-Encoding, і Content-Length, не выбірайце зручны лік: фарміраванне HTTP надае прыярытэт кадаванню перадачы і разглядае спалучэнне як магчымую памылку. Пакіньце гэты аналіз карэктнай рэалізацыі.

URL FTP праз HTTP-шлюз патрабуе праверкі канкрэтных паводзін URLConnection; ён не гарантуе, што кожны аксэсар HTTP-загалоўка паводзіць сябе як на звычайным HTTP URL у кожнай JDK. Выкарыстоўвайце length API з доўгім значэннем там, дзе метаданыя важныя, і праверце гатовы артэфакт супраць фактычна патрабаванай даўжыні або кантрольнай сумы. Чытанне цела не робіць раней адсутны загаловак бачным.

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