Failure in boundaryPosition condition for checking position validity
--------------------------------------------------------------------
Key: WSCOMMONS-328
URL: https://issues.apache.org/jira/browse/WSCOMMONS-328
Project: WS-Commons
Issue Type: Bug
Components: AXIOM
Reporter: Csorba Zoltán
Following code searches for the boundary in the given buffer, and after
skipSearch it validates the position whether the boundary extends the buffer
limit.
The check condition is wrong, because rnBoundaryLen = boundary.length+2. That
means if the boundary is found at the end of the buffer, this condition fails
although boundary is already in the buffer.
protected int boundaryPosition(byte[] searchbuf, int start, int end) throws
java.io.IOException {
if (skip == null) {
skip = ByteSearch.getSkipArray(boundary, true);
}
int foundAt = ByteSearch.skipSearch(boundary, true,searchbuf, start,
end, skip);
// First find the boundary marker
if (foundAt >= 0) { // Something was found.
if (foundAt + rnBoundaryLen > end) {
<-- THIS IS WRONG, SHOULD BE "if (foundAt + boundary.length > end) {"
foundAt = -1; // Not sure why this check is done
}
}
// Backup 2 if the boundary is preceeded by /r/n
// The /r/n are treated as part of the boundary
if (foundAt >=2) {
if (searchbuf[foundAt-2] == 13 &&
searchbuf[foundAt-1] == 10) {
foundAt = foundAt -2;
}
}
return foundAt;
}
This may cause problem in only one case: if there is one more character after
mime boundary at the end of the search buffer, then boundaryPosition returns
-1. As \r\n is prior to the boundary, the 'read' function appends '\r' to the
read buffer. This results, that searchbuf in he next loop starts with
"\nMIMEBoundary...", so '\n' will be appended to the read buffer also.
That means, an extra CRLF is written at the end of SOAP attachment in this case.
Using "if (foundAt + boundary.length > end) {" instead solves the problem.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
