"Nem tartozik rád," mondja a derék fejlesztő

org.apache.common.httpclient.HttpMethosBase#getResponseBody


int limit = getParams().getIntParameter(HttpMethodParams.BUFFER_WARN_TRIGGER_LIMIT, 1024*1024);
if ((contentLength == -1) || (contentLength > limit)) {
    LOG.warn("Going to buffer response body of large or unknown size. "
             +"Using getResponseBodyAsStream instead is recommended.");
}

Utána:


if ((contentLength == -1) || (contentLength > limit)) {
    LOG.warn("Going to buffer response body of "
             +contentLength+ " bytes (-1 means unknown)."
             +" Limit is "+limit+" bytes."
             +" Using getResponseBodyAsStream instead is recommended.");
}

Ezzel a fantasztikus fejlesztéssel kiderítettem, hogy a warning nem fog eltűnni, akármekkorára is növelem a limitet, mivel a hossz -1 (például a Transfer-Encoding: chunked miatt)

PS: Már hallottam a String.format-ról, csak hagyománytiszteletből nem akartam a -source 1.2 -target 1.2 opciókat elvenni.

( asch v | 2022. 07. 05., k – 16:43 )

Szerintem annyiból jogos, hogy ha potenciálisan végtelen nagy lehet az input - azaz a library által nincsen validálva - akkor az egészet betölteni egy pufferbe (amire utal a metódus neve) nem jó ötlet, mert ha a szerver túl nagy választ küld, akkor OOM lesz a vége. Persze ha saját magunk által feülgyelt szerverről van szó, nem "ellenséges" forrásról, akkor megengedhető lehet ilyen slendriánság. A helyes kezelési mód az, hogy streamként kérjük el, amit olvasás közben validálunk, hogy nem lett-e túl nagy. Vagy adhatna olyan API-t, ami maximálja, hogy mekkora body-t hajlandó betölteni RAM-ba.