Bug 58027

Summary: Can't save response data in JTL file,when the response data string begins with "<?xml version="1.0" encoding="UTF-8" ?>"
Product: JMeter Reporter: wangdh <cs_awater>
Component: HTTPAssignee: JMeter issues mailing list <issues>
Status: CLOSED WONTFIX    
Severity: normal    
Priority: P2    
Version: 2.13   
Target Milestone: ---   
Hardware: PC   
OS: All   
Attachments: pictue1_bug58027.jpg
pictue2_bug58027.jpg
jmeter.log
test.jtl
jmx
Test showing how to fix the sample data type

Description wangdh 2015-06-12 01:39:18 UTC
I'm testing an interface,the response is like below
<?xml version="1.0" encoding="UTF-8" ?>
<Response>
  <result>2221</result>
</Response>

But in the jtl file, the response is  null(the check box save as xml and save response data are enable)

  <responseData class="java.lang.String"/>
  <cookies class="java.lang.String"></cookies>
And i can see the response data through the view Result Tree(GUI)

I tried other HTTP request,the response data in the jtl file is ok.I think may be because it begins  with "<?xml version="1.0" encoding="UTF-8" ?>"
Comment 1 Sebb 2015-06-12 11:28:43 UTC
Does the jmeter.log file have any errors?
Comment 2 Sebb 2015-06-12 11:47:50 UTC
Are you sure that you are using version 2.13?

This works fine for me.
Comment 3 wangdh 2015-06-13 02:27:00 UTC
Created attachment 32815 [details]
pictue1_bug58027.jpg
Comment 4 wangdh 2015-06-13 02:27:21 UTC
Created attachment 32816 [details]
pictue2_bug58027.jpg
Comment 5 wangdh 2015-06-13 02:53:41 UTC
(In reply to Sebb from comment #1)
> Does the jmeter.log file have any errors?

NO,the  content in the jmeter.log file:

2015/06/13 10:49:00 INFO  - jmeter.samplers.SampleEvent: List of sample_variables: [] 
2015/06/13 10:49:00 DEBUG - jmeter.reporters.ResultCollector: Opened file: G:\test.jtl 
2015/06/13 10:49:00 INFO  - jmeter.gui.util.JMeterMenuBar: setRunning(true,*local*) 
2015/06/13 10:49:00 INFO  - jmeter.engine.StandardJMeterEngine: Starting ThreadGroup: 1 : Thread Group 
2015/06/13 10:49:00 INFO  - jmeter.engine.StandardJMeterEngine: Starting 1 threads for group Thread Group. 
2015/06/13 10:49:00 INFO  - jmeter.engine.StandardJMeterEngine: Thread will continue on error 
2015/06/13 10:49:00 INFO  - jmeter.threads.ThreadGroup: Starting thread group number 1 threads 1 ramp-up 1 perThread 1000.0 delayedStart=false 
2015/06/13 10:49:00 INFO  - jmeter.threads.ThreadGroup: Started thread group number 1 
2015/06/13 10:49:00 INFO  - jmeter.engine.StandardJMeterEngine: All thread groups have been started 
2015/06/13 10:49:00 INFO  - jmeter.threads.JMeterThread: Thread started: Thread Group 1-1 
2015/06/13 10:49:01 INFO  - jmeter.threads.JMeterThread: Thread is done: Thread Group 1-1 
2015/06/13 10:49:01 INFO  - jmeter.threads.JMeterThread: Thread finished: Thread Group 1-1 
2015/06/13 10:49:01 INFO  - jmeter.engine.StandardJMeterEngine: Notifying test listeners of end of test 
2015/06/13 10:49:01 DEBUG - jmeter.reporters.ResultCollector: Closing: G:\test.jtl 
2015/06/13 10:49:01 INFO  - jmeter.gui.util.JMeterMenuBar: setRunning(false,*local*)
Comment 6 wangdh 2015-06-13 02:54:12 UTC
(In reply to Sebb from comment #2)
> Are you sure that you are using version 2.13?
> 
> This works fine for me.

Yes
Comment 7 wangdh 2015-06-13 02:54:50 UTC
Created attachment 32817 [details]
jmeter.log
Comment 8 wangdh 2015-06-13 02:55:23 UTC
Created attachment 32818 [details]
test.jtl
Comment 9 wangdh 2015-06-13 02:56:48 UTC
Created attachment 32819 [details]
jmx
Comment 10 Sebb 2015-06-13 13:18:22 UTC
The sample JMX file does not have the correct Listener configuration, nor does it have a file name.

However I can reproduce the issue.

The problem is that the response is being treated as binary (non-text) and is therefore not saved to the file. I'm not yet sure why this is the case for that particular URL.
Comment 11 Sebb 2015-06-15 10:25:22 UTC
Turns out that problem is that the response does not include a Content-Type.

According to RFC 2616 section 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".<<

The server that is returning the content is misbehaving.
It ought to include a Content-Type so the client knows what to do without requiring additional heuristics.
Comment 12 wangdh 2015-06-16 04:23:23 UTC
(In reply to Sebb from comment #11)
> Turns out that problem is that the response does not include a Content-Type.
> 
> According to RFC 2616 section 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".<<
> 
> The server that is returning the content is misbehaving.
> It ought to include a Content-Type so the client knows what to do without
> requiring additional heuristics.

Thank you Sebb!Is there any setting in jmeter.properties file ,so that jmeter can use default Content-Type such as  text/plain.
Comment 13 Sebb 2015-06-16 12:54:05 UTC
(In reply to wangdh from comment #12)
> (In reply to Sebb from comment #11)
> Thank you Sebb!Is there any setting in jmeter.properties file ,so that
> jmeter can use default Content-Type such as  text/plain.

No.

However JMeter has Post-Processors which can be used to adjust individual results. A simple work-round is to add a BeanShell Post-Processor to the samplers that need to be fixed, and invoke the following code:

prev.setDataDatype("text");

Sample Test Plan to follow.

This will set the sample data to be of type TEXT, allowing it to be saved.

However the server really ought to be fixed.
Comment 14 Sebb 2015-06-16 12:56:25 UTC
Created attachment 32827 [details]
Test showing how to fix the sample data type

The test plan downloads the file twice; the second time the sample data type is forced to be of type TEXT
Comment 15 Sebb 2015-06-16 13:04:36 UTC
There's no bug here; JMeter is performing as designed.

However, it was not immediately obvious why the sample response was not being saved. Bug 58033 deals with this by noting the reason in the JTL file.

Bug 58041 deals with displaying the data type of a sampler.
Comment 16 wangdh 2015-06-17 00:47:12 UTC
(In reply to Sebb from comment #14)
> Created attachment 32827 [details]
> Test showing how to fix the sample data type
> 
> The test plan downloads the file twice; the second time the sample data type
> is forced to be of type TEXT

It's a good idea ,Thank you!
Comment 17 wangdh 2015-06-17 01:00:11 UTC
(In reply to Sebb from comment #15)
> There's no bug here; JMeter is performing as designed.
> 
> However, it was not immediately obvious why the sample response was not
> being saved. Bug 58033 deals with this by noting the reason in the JTL file.
> 
> Bug 58041 deals with displaying the data type of a sampler.

You helped me a lot,thank you for your patience!