On Mon, May 7, 2018 at 9:42 PM, Felix Schumacher < [email protected]> wrote:
> Am 07.05.2018 um 21:32 schrieb Philippe Mouawad: > >> On Mon, May 7, 2018 at 8:51 PM, Felix Schumacher < >> [email protected]> wrote: >> >> Am 07.05.2018 um 18:59 schrieb Vladimir Sitnikov: >>> >>> Antonio>Do you have an idea of the performance impact? >>>> >>>> I'm afraid, it is inevitable. One of the further enhancements is might >>>> be >>>> sending pre-compressed *.gz files >>>> >>>> Option 1 seems better for me >>>> It looks so. As far as I know, request body compression is not specified >>>> in >>>> the standard, so using JMeter-specific "header" to trigger the >>>> compression >>>> might be the right thing to do. >>>> >>>> For instance: >>>> X-JMeter-Content-Compression: gzip >>>> >>>> Later it could be improved to: >>>> X-JMeter-Content-Compression: gzip; compression_level=1 vs >>>> X-JMeter-Content-Compression: gzip; compression_level=9 >>>> >>>> Is there a chance that compression is different per request ? Can't it >>> be >>> >> a global settings ? >> >> Although I agree with proposition benefits, I don't find it very intuitive >> for users. >> If it's automatic: >> >> - New users or newbies don't have anything to do, it works OOTB >> > That is always a plus. > > - Users who have implemented the compression will indeed be impacted, >> but they are more advanced and we can suppose they'll read release >> notes >> and will rapidly find the issue no ? >> > I dare say, that this is not always (mostly not) the case and it is not > clear, whether the original advanced users are still the ones that run (and > debug) the tests. > True > > >> On the contrary, If users need to add those headers: >> >> - It looks to me not very intuitive >> > That is right, but it is safe. > Yes that's why I liked it as "advanced user" , but disliked it trying to figure out how newbie would do it :-) > > - it means we modify requests for JMeter only behaviour, it is correct >> ? >> Or shall we also remove headers once we compress ? which means more >> complexity in code >> > I think it would be best to remove the custom header after the part is > compressed. > I agree, but from your last answer below, it looks you finally favor a GUI option ? > > >> Anyway for all solutions we need to also modify Recorder to uncompress the >> request body as it is currently compressed (binary and unreadable). >> > If the body is compressed and the header stays intact, there is no need to > compress it and no need for a custom header, if you want to send the > compressed body, only. > > If you want to display the content, it would probably better to uncompress > it, but that would only be useful for text like content, wouldn't it? > Can we guess that underlying compressed content is text ? > > All in all, a GUI change looks like good alternative to these problems. It > could be intuitive, it can be selectively enabled and it is compatible with > the old behaviour, if defaults are set correctly. > So we go for GUI , not particular header right ? I agree with this, we should make it editable so that a variable or property can be used. > > Regards, > Felix > > > >> >> If we use just `Content-Encoding` to trigger the behavior, then it would >>>> be >>>> hard to evolve. >>>> >>>> +1 >>> >>> If we use Content-Encoding, we could break other scripts, that have >>> already compressed their payload. >>> >>> I agree, but maybe a property to disable automatic compression is a >> solution. >> >> >>> That means "body compression" might deserve its own set of UI checkboxes, >>>> however it looks like the case is rare (neither HTTP/1 nor HTTP2 specify >>>> body compression), so we might be fine to keep that behind "trigger >>>> header" >>>> to avoid UI clutter. >>>> >>>> There are major ERP like Oracle that use it for example. >> And I have seen the question on Stackoverflow a bunch of times. So I think >> it is a real requirement. >> >> >> Right, nothing stops us from adding the ui or preprocessor or other >>> mechanism after we introduce the header trigger. >>> >>> >> >> Regards, >>> Felix >>> >>> >>> Vladimir >>>> >>>> >>>> >> > -- Cordialement. Philippe Mouawad.
