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). 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?
