Handling of missing Content-Type

[sebb <se...@gmail.com>]

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?

Re: Handling of missing Content-Type

[sebb <se...@gmail.com>]

On 15 June 2015 at 11:58, sebb <se...@gmail.com> 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?