جب getContentLengthLong -1 واپس کرے تو Java پراکسی ڈاؤن لوڈز

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 خرابی ناکام ڈاؤن لوڈ ہے، کم بائٹس کے ساتھ کامیاب تکمیل نہیں۔

لمبائیوں کا موازنہ ایک ہی پرت میں کریں۔ HTTP/1.1 کی chunked انکوڈنگ Content-Length کی جگہ لے سکتی ہے اور اسے HTTP عمل درآمد ڈی کوڈ کرتا ہے۔ پراکسی اسے دوبارہ فریم کر سکتی ہے۔ ڈی کمپریشن بھی ایپلیکیشن کے ڈی کوڈ شدہ بائٹس کی تعداد کو انکوڈ شدہ Content-Length سے مختلف کر سکتا ہے۔

اگر Transfer-Encoding اور Content-Length دونوں نظر آئیں تو آسان نمبر نہ چنیں: HTTP فریمنگ ٹرانسفر انکوڈنگ کو ترجیح دیتی ہے اور اس امتزاج کو ممکنہ خرابی سمجھتی ہے۔ وہ پارسنگ موزوں عمل درآمد پر چھوڑ دیں۔

HTTP گیٹ وے کے ذریعے FTP URL کے لیے اس کے ٹھوس URLConnection رویے کی جانچ ضروری ہے؛ یہ ضمانت نہیں دیتا کہ ہر HTTP ہیڈر ایکسیسر ہر JDK میں عام HTTP URL کی طرح برتاؤ کرے گا۔ جہاں میٹاڈیٹا اہم ہو وہاں طویل قدر والی length API استعمال کریں، اور مکمل شدہ آرٹیفیکٹ کو واقعی مطلوبہ لمبائی یا چیک سم کے خلاف توثیق کریں۔ باڈی پڑھنے سے پہلے غائب ہیڈر ظاہر نہیں ہوتا۔