jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philippe Mouawad <philippe.moua...@gmail.com>
Subject Re: Regression in 3.0 / Bug 59401 / Possible solutions
Date Sun, 01 May 2016 21:14:08 GMT
On Sunday, May 1, 2016, sebb <sebbaz@gmail.com> wrote:

> On 1 May 2016 at 21:27, Philippe Mouawad <philippe.mouawad@gmail.com
> <javascript:;>> wrote:
> > On Sunday, May 1, 2016, sebb <sebbaz@gmail.com <javascript:;>> wrote:
> >
> >> On 1 May 2016 at 21:12, Philippe Mouawad <philippe.mouawad@gmail.com
> <javascript:;>
> >> <javascript:;>> wrote:
> >> > On Sunday, May 1, 2016, sebb <sebbaz@gmail.com <javascript:;>
> <javascript:;>> wrote:
> >> >
> >> >> On 1 May 2016 at 20:53, Philippe Mouawad <philippe.mouawad@gmail.com
> <javascript:;>
> >> <javascript:;>
> >> >> <javascript:;>> wrote:
> >> >> > Hello,
> >> >> > As you know a regression has been reported on 3.0 related to
> >> Compressed
> >> >> > responses management.
> >> >> >
> >> >> > HC4.5.2 differs in its behaviour with 4.2.6, it removes 3 headers
> >> after
> >> >> > uncompressing the response:
> >> >> > - Content-Length
> >> >> > - Content-Encoding
> >> >> > - Content-MD5
> >> >> >
> >> >> > I attached a fix to Bug 59401 that introduces a
> ResponseInterceptor at
> >> >> > first position to save initial Headers.
> >> >> > These headers are then used by JMeter to fill in
> >> >> > SampleResult#responseHeaders
> >> >> >
> >> >> > I don't think the fix can introduce regressions but your review
is
> >> >> welcome
> >> >> > as long as alternative solutions proposals.
> >> >> >
> >> >> > The drawback I see in this patch is that it introduces a new
> >> >> > ResponseInterceptor and saves Headers in localContext impacting
> >> slightly
> >> >> > memory and CPU usage.
> >> >> >
> >> >> >
> >> >> > An alternative solution, would be to modify slightly
> >> >> >
> >> >>
> >>
> https://github.com/apache/httpclient/blob/4.5.x/httpclient/src/main/java/org/apache/http/client/protocol/ResponseContentEncoding.java#L142
> >> >> > to remove the code that removes the headers.
> >> >>
> >> >> -1; the headers cannot remain as they are no longer correct.
> >> >>
> >> >> But this can break existing test plans that would use the missing
> >> headers
> >> > no ?
> >> >
> >> >> However an alternative might be to copy the original values to an
> >> >> X-prefixed header before removal.
> >> >
> >> > isn't it strange that JMeter adds headers ?
> >> > How users can distinguish between servers headers and jmeter ones ?
> >>
> >> X-JMeter-Content-xxx
> >>
> >> Also JMeter can remove them again before storing the response.
> >> They would only be used as temporary storage
> >
> >
> > I don't get the whole picture of what you propose ans how it
> > avoid breaking tests.
>
> You were proposing to add a ResponseInterceptor that saves the headers
> in localContext
>
> I'm suggesting saving them on the response instead.
>
> So when processing the response, JMeter looks for
>
> X-JMeter-Content-xxx
> rather than
> Content-xxx
>
> This assumes it knows which reponses have been uncompressed.
>
> Alternatively, if it cannot find Content-xxx it looks for
> X-JMeter-Content-xxx.


Doing so it changes response size.
I'm afraid of the impacts of this solution and possible regressions.
But a patch would make it clear for me.




>
> > Could you provide a patch ?
> >
> > thanks
> >
> >
> >>
> >>
> >>
> >
> >> Thx
> >> >
> >> >>
> >> >> >
> >> >> >
> >> >> > Regards
> >> >> > Philippe
> >> >>
> >> >
> >> >
> >> > --
> >> > Cordialement.
> >> > Philippe Mouawad.
> >>
> >
> >
> > --
> > Cordialement.
> > Philippe Mouawad.
>


-- 
Cordialement.
Philippe Mouawad.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message