>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
|