Bug 44784 - Web Proxy does not handle malformed Content Type gracefully
Web Proxy does not handle malformed Content Type gracefully
Status: RESOLVED FIXED
Product: JMeter
Classification: Unclassified
Component: HTTP
Nightly (Please specify date)
PC Windows XP
: P3 normal (vote)
: ---
Assigned To: JMeter issues mailing list
:
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2008-04-09 03:36 UTC by Robert Rees
Modified: 2008-04-23 09:13 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Robert Rees 2008-04-09 03:36:32 UTC
I was using the Web Proxy to capture a transaction on a website that was sending malformed ContentType in the response. The content type was of the format: charset=x;charset=x.

After extraction the store of the sample failed showing a 503 error on the browser and a UnsupportedEncoding exception in the log (the encoding being passed to the String constructor being of the form "x;charset=x").

Looking into the error I saw that the problem was occurring in the Proxy.getContentEncoding method. I also noticed that there were three getContentEncoding methods at different levels (document, etc) all of which use slightly different versions of the indexOf followed by substring index strategy for extraction.

I solved my problem by using the regexp below and defaulting to the platform encoding if the expression does not match.

Pattern p = Pattern.compile("charset=([\\d\\w-]+)");

This simply extracted the first sequence in the charset.

I think the Proxy needs to be more forgiving in its parsing of the Content-Type and if it is malformed use a sensible default as browsers do. I also think that the Content Type extractor should check whether the coding extracted is actually one supported by the Java platform that is running JMeter. It is easier to debug if the failure occurs closer to the source of the problem instead of failing on the store of the Sampler.

This problem occurred on an SVN tip build of 28th of March and is still occurring as far as I know.
Comment 1 Sebb 2008-04-16 18:33:40 UTC
According to

http://www.iana.org/assignments/character-sets

charset names may be up to 40 characters of the US-ASCII character set, which would include ";" and space, tab etc.

The document cited above lists some charset formal names which also include "." and "-".

Unless you can find a formal definition of the allowable characters for a charset, I think it would be safest to assume only that ";" is not allowed.

This is what has been fixed in SVN in 

http://svn.apache.org/viewvc?rev=648909&view=rev
http://svn.apache.org/viewvc?rev=648910&view=rev
http://svn.apache.org/viewvc?rev=648916&view=rev
Comment 2 Robert Rees 2008-04-23 08:22:15 UTC
(In reply to comment #1)
> According to
> 
> http://www.iana.org/assignments/character-sets

> Unless you can find a formal definition of the allowable characters for a
> charset, I think it would be safest to assume only that ";" is not allowed.

I'm happy with this as a solution for the extraction. The refactor to a Helper class makes it easier to read the code too.

But if the server specifies a charset that the JVM doesn't support you will still get an invalid captured sampler. I think that the new conversion method should check Charset.isSupported on the captured charset and if the answer is false return Charset.defaultCharset().name().

That way getEncodingFromContentType will always return a valid encoding for the platform. 
Comment 3 Sebb 2008-04-23 09:13:25 UTC
OK, added check for unsupported Charset:

http://svn.apache.org/viewvc?rev=650928&view=rev