You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commons-dev@ws.apache.org by "Csorba Zoltán (JIRA)" <ji...@apache.org> on 2008/04/22 09:27:21 UTC
[jira] Updated: (WSCOMMONS-328) Failure in boundaryPosition
condition for checking position validity
[ https://issues.apache.org/jira/browse/WSCOMMONS-328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Csorba Zoltán updated WSCOMMONS-328:
------------------------------------
Description:
org.apache.axiom.attachments.BoundaryPushbackInputStream
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.
was:
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.
> 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
>
> org.apache.axiom.attachments.BoundaryPushbackInputStream
> 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.