[
https://issues.apache.org/jira/browse/WSCOMMONS-328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Veithen resolved WSCOMMONS-328.
---------------------------------------
Resolution: Fixed
Fix Version/s: Axiom 1.2.8
Assignee: Andreas Veithen
Actually the condition "foundAt + boundary.length > end" is never true, so the
entire if statement should be removed. I added a unit test that confirms your
analysis and fixed the code. Thanks for spotting this issue!
> 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
> Assignee: Andreas Veithen
> Fix For: Axiom 1.2.8
>
>
> 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.
