Summary: | Web Proxy does not handle malformed Content Type gracefully | ||
---|---|---|---|
Product: | JMeter - Now in Github | Reporter: | Robert Rees <robert.rees> |
Component: | HTTP | Assignee: | JMeter issues mailing list <issues> |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | P3 | ||
Version: | Nightly (Please specify date) | ||
Target Milestone: | --- | ||
Hardware: | PC | ||
OS: | Windows XP |
Description
Robert Rees
2008-04-09 03:36:32 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 (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. OK, added check for unsupported Charset: http://svn.apache.org/viewvc?rev=650928&view=rev This issue has been migrated to GitHub: https://github.com/apache/jmeter/issues/2094 |