jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vladimir Sitnikov <sitnikov.vladi...@gmail.com>
Subject Re: BUG 61748 / Request compression
Date Mon, 07 May 2018 20:01:25 GMT
>Yes that's why I liked it as "advanced user" , but disliked it trying to
figure out how newbie would do it :-)

Technically speaking, Recorder could identify "compressed" requests and
record accordingly.
E.g. mark the samplers with X-JMeter-Compression (or with a UI checkbox if
you are fond of developing UIs :) )

As you say, Recorder would have to be modified to uncompress the data for
recording purposes.

It could be a stretch, but I do not see why `gzip` encoding should be
treated much different from json/xml encodings.

>but disliked it trying to figure out how newbie would do it :-)

Recording is a sane thing for scaffolding a new test.

>I agree, but from your last answer below, it looks you finally favor a GUI
option ?

Frankly speaking, I'm not that fond of UI development (I'm a bad UI
designer), and I find current UI cluttered (as in "I do not find a good
approach to add new option for every feature added"). Should "body
encoding" be configureable beyond gzip?
For instance, once upon a time there were Flash requests. Should content
option be "gzip / flash"?

>Can we guess that underlying compressed content is text ?

I think Recorder can do content sniffing and it could just know "well-known
headers that designate the request was encoded with known to JMeter
wrapper".

Vladimir

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