Java אַראָפּלאָדונגען דורך פּראָקסי ווען getContentLengthLong גיט צוריק -1

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 געהערט צום רופֿער. האַלט די פֿאַרבינדונג און לייען־צייטלימיטן און יעדער באַגרענעצונג פֿון דער אַפּפּליקאַציע אַרום דעם שלייף. אַן I/O פֿעלער איז אַ דורכגעפֿאַלענע אַראָפּלאָדונג, נישט אַ דערפֿאָלגרייַכע פֿאַרענדיקונג מיט ווייניקער בייטן.

פֿאַרגלײַכט לענגען אויף דער זעלביקער שיכטע. די chunked קאָדירונג פֿון HTTP/1.1 קען פֿאַרבייַטן Content-Length און ווערט דעקאָדירט דורך דער HTTP אימפּלעמענטאַציע. אַ פּראָקסי קען עס איבערמאַכן. דעקומפּרעסיע קען אויך מאַכן די דעקאָדירטע בייטן־צאָל פֿון דער אַפּפּליקאַציע אַנדערש פֿון אַ קאָדירטער Content-Length.

אויב עס דערשיינען סיי Transfer-Encoding סיי Content-Length, קלייבט נישט קיין באַקוועמער צאָל: HTTP ראַמע גיט פּריאָריטעט צו דער איבערגאַנג־קאָדירונג און באַטראַכט די קאָמבינאַציע ווי אַ מעגלעכער פֿעלער. לאָזט די פּאַרסונג צו אַ פּאַסיקער אימפּלעמענטאַציע.

אַן FTP URL דורך אַ HTTP־טויער פֿאָדערט אַ פּריפֿונג פֿון דעם קאָנקרעטן URLConnection־פֿאַרהאַלטן; עס גאַראַנטירט נישט אַז יעדער HTTP־קעפּל־צוטריט פֿירט זיך ווי אויף אַ געוויינטלעכן HTTP URL אין יעדער JDK. ניצט די length API מיט לאַנגער ווערט וווּ מעטאַדאַטן זענען וויכטיק, און באַשטעטיקט דאָס פֿאַרטיקע אַרטעפֿאַקט קעגן דער טאַקע פֿאָדערלעכער לענג אָדער קעקסאַם. דאָס לייענען דעם קערפּער מאַכט נישט אַ פֿריִערדיקן פֿעלנדיקן קעפּל דערשיינען.