computeContentEncoding[DefaultSamplerCreator.java] fail to identify correct encoding

[Prajjwal Laad <Pr...@india.nec.com>]

Hello,

Following the fix of Bug 63129, I had a query and I have my test scenario as following: 

page1.jsp -> charset=Windows-31J
page2.jsp -> charset=UTF-8
JMeter Proxy with default encoding as UTF-8.

page1 sends a POST request with a Windows-31J encoded string and lands on page2. On page2 I am retrieving the string.
	<form action="page2.jsp">

When I hit submit on page1, computeContentEncoding[DefaultSamplerCreator.java] method calculates encoding of page2 [UTF-8] instead of page1 [Windows-31J] and hence garbling the Windows-31J encoded string.
Note: Request header doesn't specify encoding.

I wanted to know if we can also check for the current page's [page1] encoding so that the POST data can be decoded properly? Request you to please share your views.

Environment details:
os.name=Windows 8.1
java.version=1.8.0_201
Locale: en_IN
file.encoding=Cp1252


Thanks and Regards,
Prajjwal Laad

RE: computeContentEncoding[DefaultSamplerCreator.java] fail to identify correct encoding

[Naveen Nandwani <na...@india.nec.com>]

Dear Team,

Referring to below mail, one of our scenario is failed while encoding using JMeter.
As per following commit, one parameter "proxy_default_encoding" was added:
https://github.com/apache/jmeter/commit/74ce954f3e13aad728e9e8541fd18c52150636a6

It can solve the issue, if first time page is loaded by proxy, then current page and next page encoding is not present in pageEncodings map.
Proxy_default_encoding provided by user is used.
But when second time execution is done for the same page, which does not specify page encoding, 
then computeContentEncoding() of DefaultSamplerCreator.java:346, extracts the url of next page:
String urlWithoutQuery = request.getUrlWithoutQuery(pageUrl);

But as per our understanding, if encoding should be done as per current page encoding and not next page encoding.

Could you please confirm, the existing design, why encoding of next page is use to encode the value in HTTPArgument() method of HTTPArgument.java:143 class.
Based on existing design of JMeter proxy module, we want to propose new design to solve our case.
Also seek recommendation from community to solve our issue.

Please let us know, if more details are required to be shared.

Regards,
Naveen Nandwani

-----Original Message-----
From: Prajjwal Laad [mailto:Prajjwal.Laad@india.nec.com] 
Sent: 24 July 2019 20:33
To: dev@jmeter.apache.org
Subject: computeContentEncoding[DefaultSamplerCreator.java] fail to identify correct encoding

Hello,

Following the fix of Bug 63129, I had a query and I have my test scenario as following: 

page1.jsp -> charset=Windows-31J
page2.jsp -> charset=UTF-8
JMeter Proxy with default encoding as UTF-8.

page1 sends a POST request with a Windows-31J encoded string and lands on page2. On page2 I am retrieving the string.
	<form action="page2.jsp">

When I hit submit on page1, computeContentEncoding[DefaultSamplerCreator.java] method calculates encoding of page2 [UTF-8] instead of page1 [Windows-31J] and hence garbling the Windows-31J encoded string.
Note: Request header doesn't specify encoding.

I wanted to know if we can also check for the current page's [page1] encoding so that the POST data can be decoded properly? Request you to please share your views.

Environment details:
os.name=Windows 8.1
java.version=1.8.0_201
Locale: en_IN
file.encoding=Cp1252


Thanks and Regards,
Prajjwal Laad