>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
