Recent changes to bugs

Set encoding override not available

Jason Pell — Tue, 01 May 2007 15:47:40 -0000

In the 2.00b6 implementation the encoding is obtained from the context HttpServletRequest.getEncoding method. However there should be provision to pass in an overriding encoding value. This should be very straightforward, as the member to control the encoding is a instance member not a class member:

private String m_charEncoding;

Will add it to the main constructor in the 2.00b7 release

Either that or provide the ability to set it via a system property. I think the param is probably the best bet, and if its specified as null, use the default of ISO-8859-1

ServletMultipartRequest.getFileContents(String)

Anonymous — Thu, 25 Sep 2003 16:46:57 -0000

Hi,

While trying to obtain file contents in a file whose length
is 0 (eg. an empty probe.txt), returns null.

I suppose it's not the desirable behaviour. It avoids, for
example, preparing a file to attach in a web mail
application. No mail clients refuse to send an empty file...

Best regards and thanks a lot

carlos
cfmoro@correo.uniovi.es

IE 6.0 upload problem

Jason Pell — Wed, 26 Feb 2003 05:41:37 -0000

Jason:

We have been tracing a very weird bug for quite a while
and have finally
found the issue. Please see the following two postings
regarding two
separate bugs with dumb @#$$%&^@#! IE browsers.

http://bugs.php.net/bug.php?id=18792

and

http://www.servlets.com/blog/archives/000032.html
(Look at the first
comment by user alim)

Based on these two problems, may I propose the
following two changes to the
code:

In initParser(...) determine the strBoundary as:

strBoundary = null;
if (strContentTypeText!=null &&
strContentTypeText.toLowerCase().startsWith("multipart/form-data"))
{
// This is done to handle IE and netscape
proxies incorrectly
setting the boundary
// (for this bug see
http://bugs.php.net/bug.php?id=18792\)
int startNdx =
strContentTypeText.indexOf("boundary=");
if (startNdx >= 0) {
int endNdx =
strContentTypeText.indexOf(",",startNdx+9);
if (endNdx < 0)
strBoundary =
strContentTypeText.substring(startNdx+9);
else
strBoundary =
strContentTypeText.substring(startNdx+9,endNdx);
strBoundary = strBoundary.trim();
}
}

if (strBoundary == null) {
// <mtl,jpell>
debug("ContentType = " + strContentTypeText);
throw new IllegalArgumentException("Invalid
Content Type.");
}

And then at the beginning of parse(..)

// Must be boundary at top of loop, otherwise
we have finished.
// However, lovely IE 6.0 wigs out with some
strange chars in the
form fields
boolean foundFirstBoundary = false;
while ((read=readLine(in, blockOfBytes)) > 0) {
strLine = (read>0)? new
String(blockOfBytes, 0, read,
charEncoding): null;
if (strLine!=null &&
strLine.indexOf(this.strBoundary) >= 0) {
foundFirstBoundary = true;
break;
}
}
if (!foundFirstBoundary) {
throw new IOException("Invalid Form Data,
no boundary
encountered.");
}

Let me know. As always, thanks

-Luis

Problems with TrimQuotes method

Jason Pell — Wed, 26 Feb 2003 05:40:51 -0000

Jason,

I have recently come across another issue with the
multipart parser that you may wish to be aware of.

I have had an issue raised with the parser:

"Creating a file with a japanese filename and writing a
japanese comment to that filename causes the following
exception:

java.lang.StringIndexOutOfBoundsException: String index
out of range: -1
java.lang.String.charAt(String.java:460)
http.utils.multipartrequest.MultipartRequest.trimQuotes(MultipartRequest.java)
http.utils.multipartrequest.MultipartRequest.parse(MultipartRequest.java)
http.utils.multipartrequest.MultipartRequest.init(MultipartRequest.java)
http.utils.multipartrequest.MultipartRequest.(MultipartRequest.java)
"

More information can be found here:
http://jira.atlassian.com/secure/ViewIssue.jspa?key=JRA-1255

From looking at the code for trimQuotes, this exception
looks as though it can happen if you upload a file,
with a filename of a single quote, or a quote & whitespace.

private static final String trimQuotes (String strItem)
{
// Saves having to go any further....
if (strItem==null || strItem.indexOf("\&quot;")==-1)
return strItem;

// Get rid of any whitespace..
strItem = strItem.trim();

if (strItem.charAt(0) == '\&quot;')
strItem = strItem.substring(1);

if (strItem.charAt(strItem.length()-1) == '\&quot;')
strItem = strItem.substring(0, strItem.length()-1);

return strItem;
}

So trimQuotes(" \&quot; "); will fail with an exception.

The fix should be very simple, you need to change this
line:

if (strItem.charAt(strItem.length()-1) == '\&quot;')

if (strItem.length() > 0 &&
strItem.charAt(strItem.length()-1) == '\&quot;')

I have no idea why this would happen on japanese
filenames though!

Thanks for your help, and your response so far.

Cheers,
Scott

Compile MultipartRequest - with fix

Rob Gaunt — Tue, 22 Oct 2002 10:19:45 -0000

public static synchronized void setEncoding(String
enc)throws UnsupportedEncodingException

...

new String(new byte[]{'\n'}, enc);

...

Needs to be changed to
new String(new byte[]{(byte)'\n'}, enc);

on my machine.

Stream ended prematurely

Anonymous — Mon, 08 Apr 2002 07:01:02 -0000

The class gives an error as "Stream ended prematurely"
while uploading .doc, .jpeg etc. It work proper only
for .txt, .htm, .html. And attimes for some of
the .doc files. Cannot guess the reason. Also if
the .doc, .jpeg files are uploaded they are possibly
corrupted, as they do not open. The MultiPartRequest
class is used with Tomacat 4.0.1-Apache on Linux 7.1.
What is going wrong is unpredictable, since the same
code works fine on Windows 98.

Encoding and constructor

Jacek Bator — Fri, 08 Mar 2002 12:02:16 -0000

Hello
I have problem with MultipartRequest and international
characters in uft8 format. I can call method
setEncoding after constructor, but constructor parses
input request with default encoding iso-8859-1, so how
can I parse my request with desired encoding. For my
development first call for MultipartRequest parses data
incorectly (changes international characters to two
characters) but second call for this class seems to
work correctly. And this is my second doubt. Field
charEncoding is declared static. This is the reason why
second time parsing works but when on one container two
servlets will try to parse content with different
encogings there will be lots of problems. For me there
are two possible solutions (except removing static):
- add encoding parameter to constructor (less work)
- delay parsing of request till first call for
retriving data from it (like it works with original
HttpServletRequest (at least in tomcat)), which is my
favourite solution, but reqires little bit more codding

If you want I can make some of coding and send you
resoults. For now solution for me is to simply change
default encoding for utf8

Best Regards

Jacek Bator

IE4 on Mac

Jason Pell — Thu, 14 Feb 2002 07:48:31 -0000

IE4 on a mac adds extra empty lines after last
boundary. This causes MultipartRequest to break as it
assumes another url parameter.