DO NOT REPLY [Bug 21269] New: - FileUploadBase does not handle quoted boundary specification, which is required by RFC 1521

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21269>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21269

FileUploadBase does not handle quoted boundary specification, which is required by RFC 1521 

           Summary: FileUploadBase does not handle quoted boundary
                    specification, which is required by RFC 1521
           Product: Commons
           Version: 1.0 Final
          Platform: All
               URL: http://www.faqs.org/rfcs/rfc1521.html
        OS/Version: All
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: File Upload
        AssignedTo: commons-dev@jakarta.apache.org
        ReportedBy: peter.chase@globalgraphics.com


In FileUploadBase.parseRequest(), the boundary string is computed by:

  int boundaryIndex = contentType.indexOf("boundary=");
  byte[] boundary = contentType.substring(boundaryIndex + 9).getBytes();

This is OK if the boundary string is unquoted. But RFC 1521 states clearly 
that boundary strings may, and in some cases must, be quoted.

The consequence is that a request containing a quoted boundary string fails to 
parse. The exact behaviour is that the parsing completes "successfully" but no 
FileItems are found.

The code should look for a leading quote and, if found, move on by one 
character before reading the boundary string. Perhaps it should check for the 
trailing quote, too. Your test suites should be extended to test this case.

The examples in RFC 1521 show double quotes being used, and that is what 
provoked the failure in the system I am trying to build. However, single 
quotes may also be allowed (it probably says yes or no somewhere in the RFC).

If confirmed to be correct, I think that this is quite a serious fault, 
requiring rapid attention. I have not provided a proposed patch, at this 
stage, but would be willing to do so, if asked.

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org