On 11 May 2016 at 21:47, Philippe Mouawad <[email protected]> wrote: > On Wed, May 11, 2016 at 10:44 PM, sebb <[email protected]> wrote: > >> On 11 May 2016 at 21:30, Philippe Mouawad <[email protected]> >> wrote: >> > Hello, >> > We have an issue in current 3.0 rc4 as seen by Rainer : >> > - https://issues.apache.org/jira/browse/HTTPCLIENT-1742 >> > >> > The issue is due to a behavioral change in HttpClient 4.5.2 vs >> > httpclient-4.2.6: >> > >> > - ResponseContentEncoding removes 3 headers from Response : >> > Content-Encoding, Content-Length, Content-MD5 >> > - JMeter uses DefaultRequestDirector which is replaced by >> MainClientExec >> > >> > >> > Now here is what happens: >> > >> > At this line, PostProcessor run , leading to removal of 3 headers >> > >> > - >> > >> https://github.com/apache/httpclient/blob/4.5.x/httpclient/src/main/java-deprecated/org/apache/http/impl/client/DefaultRequestDirector.java#L496 >> > >> > At the next line, keepAlive management is run, but it's too late as >> headers >> > have been removed: >> > >> > - >> > >> https://github.com/apache/httpclient/blob/4.5.x/httpclient/src/main/java-deprecated/org/apache/http/impl/client/DefaultRequestDirector.java#L500 >> > >> > >> > While in new HC Class ProtocolExec: >> > >> > The keepAlive is managed in this >> > >> > >> https://github.com/apache/httpclient/blob/4.5.x/httpclient/src/main/java/org/apache/http/impl/execchain/ProtocolExec.java#L184 >> > >> > Which calls this: >> > >> > >> https://github.com/apache/httpclient/blob/4.5.x/httpclient/src/main/java/org/apache/http/impl/execchain/MainClientExec.java#L274 >> > >> > And Compression is managed afterwards in : >> > >> > >> https://github.com/apache/httpclient/blob/4.5.x/httpclient/src/main/java/org/apache/http/impl/execchain/ProtocolExec.java#L189 >> > >> > >> > So no issue in HC4.5.2, but in JMeter. I think it's unfortunately a >> stopper >> > for the release. >> > >> > Breaking KeepAlive is a big issue >> >> However it only occurs if compression is used. >> > > Unfortunately nowadays, I don't see many applications that don't.
Surely applications should not send compressed content unless the client says it can accept it? So it would only affect test plans that send the appropriate headers. > >> >> It occurs to me that a much simpler way to restore the headers would >> be to save them, call the parent method, then restore them. >> > Yes, but I am just concerned about the change in order of headers. Can't it > break some Hash that would be made on them. Seems unlikely, since HC does not care whether they are present or not. They were only dropped to avoid misleading clients about the response. If necessary it might be possible to restore the order as well. But I suspect that is overkill. > > >> No need to mess around with using the context. >> > > Another option is to have an override of ResponseContentEncoding that does > not remove these headers. That means copying all the code, which you said you did not want to do... Or change the Keep-Alive calculation to use the saved header. > >> Basically that would revert the change made to HC4.5. >> > > > >> >> This would be a quicker fix than updating the code to use >> non-deprecated methods. >> Though we do need to get started on that soon. >> > Agreed > >> >> > -- >> > Regards. >> > Philippe >> > > > > -- > Cordialement. > Philippe Mouawad.
