AbstractHttpSenderConnection does not immediately recognise HTTP 204 has no content-length [SWS-583] #701
Description
Adam Healey opened SWS-583 and commented
The hasResponse() method in AbstractHttpSenderConnection currently only has specific logic for the HTTP 202 status code, immediately returning false. If a 204 is received without the Conent-Length header set (not mandatory as by definition a 204 has no content), the method will go straight to inferring the content-length by trying to read the input stream. The input stream will not contain any content and so it is left to the client server's keepAliveTimeout value to close the stream and cause the method to finish.
Although the correct result is returned from the method, it would be much better if there was a simple check for the 204 status to return false straight away.
This caused issues with our system as our sending method which uses the WebServiceTemplate took 20 seconds to finish even though the HTTP 204 was received within a few ms (the 20 seconds was configured on the client's server).
The first if statement in the current method could be adapted (with a new STATUS_NO_CONTENT added to the HttpTransportConstants representing 204):
protected final boolean hasResponse() throws IOException {
if (HttpTransportConstants.STATUS_ACCEPTED == getResponseCode()) {
return false;
}
long contentLength = getResponseContentLength();
if (contentLength < 0) {
if (responseBuffer == null) {
responseBuffer = FileCopyUtils.copyToByteArray(getRawResponseInputStream());
}
contentLength = responseBuffer.length;
}
return contentLength > 0;
}
Affects: 1.5.8