On 15 June 2015 at 11:58, sebb <[email protected]> wrote: > Bug 58027 was raised recently because JMeter was not saving an XML response. > Turns out this was because the response does not contain a > Content-Type, and so the method SampleResult.setEncodingAndType(String > ct) was not being called. > > This meant that the dataType was not set to either BINARY nor TEXT. > The SampleResultConverter only saves TEXT sample responses. > > According to RFC 2616 7.2.1: > >>>Any HTTP/1.1 message containing an entity-body SHOULD include a Content-Type >>>header field defining the media type of that body. If and only if the media >>>type is not given by a Content-Type field, the recipient MAY attempt to >>>guess the media type via inspection of its content and/or the name >>>extension(s) of the URI used to identify the resource. If the media type >>>remains unknown, the recipient SHOULD treat it as type >>>"application/octet-stream".<< > > Should JMeter do anything about this? > > Various options are possible. > > 1) SampleResultConverter could save responses with null dataType (Tree > View displays these).
Note that XStream seems to be able to save/restore binary data. However it probably does not make sense to default to saving binary data. > 2) JMeter could examine the URI path to try and determine if the > response is likely to be TEXT. Extracting the URI name extension is > simple, but maintaining the list of text/binary extensions would be a > pain. And some extensions are used for both binary and text files (on > different systems). > > 3) JMeter could examine the body to determine if it is text. This > might be expensive, though perhaps the check could be limited to the > first N characters. > > Each of the above options has some disadvantages, so would need to be > made optional, e.g. via a property. > > Thoughts?
