Rewrite CloseableHttpResponse to ClassicHttpResponse and use executeOpen#210
Rewrite CloseableHttpResponse to ClassicHttpResponse and use executeOpen#210
Conversation
When using CloseableHttpResponse and execute() with a response handler, the http connection was closed after the response handler terminated. Returning the http response was not feasible because the http connection was closed and thus so was the InputStream with the content of the response. Using executeOpen() keeps the connection open and makes it possible to return the response object for later use. The InputStream remains open and unconsumed. The caller, howevever, is now responsible for closing the InputStream and by extension also the Http connection. This is easily done as pointed out in the examples with a try-with-resources.
|
Should fix #209 |
|
Synes det er vanskelig å mene noe om dette er safe eller ikke. Jeg har ikke nok oversikt over hele API-flaten (som er ganske stor) denne klienten tilbyr nå. Det jeg legger merke til er at det nå virker som alle requests nå bruker Jeg tror jeg selv ville foretrukket å konsekvent bruke Bare nevner også at å endre returtypen til en metode er en ikke-binærkompatibel endring, sånn med tanke på versjonering. Dersom noe kode et eller annet sted er kompilert mot tidligere variant av en metode, så vil det kræsje hvis denne metoden får en ny versjon av biblioteket. |
|
Jeg tror at denne endringen er ok å legge ut i v17, fordi den gjør "ferdig" overgangen til HttpClient5 som vel var årsaken til at 17 ble en major release. Men vi bør kanskje skrive noe om det i versjonen-informasjonen. |
When using CloseableHttpResponse and execute() with a response handler, the http connection was closed after the response handler terminated. Returning the http response was not feasible because the http connection was closed and thus so was the InputStream with the content of the response.
Using executeOpen() keeps the connection open and makes it possible to return the response object for later use. The InputStream remains open and unconsumed. The caller, howevever, is now responsible for closing the InputStream and by extension also the Http connection. This is easily done as pointed out in the examples with a try-with-resources.