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 ให้ลำดับความสำคัญกับการเข้ารหัสการถ่ายโอนและถือว่าการรวมกันนั้นเป็นข้อผิดพลาดที่อาจเกิดขึ้น ปล่อยการแยกวิเคราะห์นั้นให้กับการทำงานที่สอดคล้อง

URL แบบ FTP ผ่านเกตเวย์ HTTP ต้องตรวจสอบพฤติกรรม URLConnection ที่เป็นรูปธรรม ไม่ได้รับประกันว่าตัวเข้าถึงส่วนหัว HTTP ทุกตัวจะทำงานเหมือน URL HTTP ปกติในทุก JDK ใช้ length API ที่มีค่าระยะยาวในจุดที่เมทาดาทาสำคัญ และตรวจสอบสิ่งส่งมอบที่เสร็จสมบูรณ์เทียบกับความยาวหรือเช็กซัมที่ต้องการจริง การอ่านเนื้อหาไม่ทำให้ส่วนหัวที่หายไปก่อนหน้านี้ปรากฏขึ้น

บทความที่เกี่ยวข้อง