تنزيلات 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. أبقِ مهَل الاتصال والقراءة وأي حد لحجم التطبيق حول هذه الحلقة. خطأ الإدخال/الإخراج هو تنزيل فاشل، وليس إكمالًا ناجحًا ببايتات أقل.

قارن الأطوال في الطبقة نفسها. يمكن لترميز chunked في HTTP/1.1 أن يحل محل Content-Length ويُفكَّك بواسطة تنفيذ HTTP. وقد يعيد البروكسي تأطيره. كما أن فك الضغط قد يجعل عدد البايتات المفكوكة في التطبيق يختلف عن Content-Length المرمّز.

إذا ظهر Transfer-Encoding وContent-Length معًا، فلا تختر رقمًا مناسبًا: تأطير HTTP يعطي أولوية لترميز النقل ويعتبر الجمع خطأً محتملاً. اترك ذلك التحليل لتنفيذ متوافق.

يحتاج عنوان FTP عبر بوابة HTTP إلى التحقق من سلوك URLConnection الملموس؛ فهو لا يضمن أن كل وصول إلى ترويسة HTTP يتصرف كعنوان HTTP عادي في كل JDK. استخدم واجهة الطول ذات القيمة الطويلة حيث تهم البيانات الوصفية، وتحقق من العنصر المكتمل مقابل الطول أو المجموع الاختباري المطلوب فعلاً. قراءة الجسم لا تجعل ترويسة غائبة سابقًا تظهر.