https://issues.apache.org/bugzilla/show_bug.cgi?id=49960
Summary: HttpServletRequest.getCharacterEncoding does not break
up the Content-Disposition header well.
Product: Tomcat 5
Version: 5.5.23
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Catalina
AssignedTo: dev@tomcat.apache.org
ReportedBy: nig...@forwardcomputers.co.uk
This probably affects all versions, not just 5.5.23.
It comes down to the utility class org.apache.tomcat.util.http.ContentType
It has the code:
// Basically return everything after ";charset="
// If no charset specified, use the HTTP default (ASCII) character set.
public static String getCharsetFromContentType(String type) {
Which is basically lazy. It can't use everything after ";charset=". It *must*
parse it and see if there is another ";"
Because if someone sets the Content-Disposition header in an XHR, it might BY
NO FAULT OF THAT DEVELOPER end up as
Content-Type: multipart/form-data; charset=UTF-8;
boundary=--------------------ext-ux-upload-boundary
That's taken directly from the Fiddler debugging tool. The browser (Firefox)
INSERTED its encoding name (UTF-8 is mandated for XHRs) within the header which
I specified. It did not append it, it INSERTED it.
Now, the character set ends up as "UTF-8;
boundary=--------------------ext-ux-upload-boundary"
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
