Quoting Thomas Butter <[EMAIL PROTECTED]>:
>I think the problem won't be triggered by a small buffer,
>but by tcp packet that ends 1 byte after the current buffer.
>If the next packet didn't arrive when fill() is triggered
>the next time then pos==0 and count==1, the read then does a
>pos++.
Here's the code :
while (!space) {
// if the buffer is full, extend it
if (readCount >= maxRead) {
if ((2 * maxRead) <= HttpRequestLine.MAX_METHOD_SIZE) {
char[] newBuffer = new char[2 * maxRead];
System.arraycopy(requestLine.method, 0, newBuffer, 0,
maxRead);
requestLine.method = newBuffer;
maxRead = requestLine.method.length;
} else {
throw new IOException
(sm.getString("requestStream.readline.toolong"));
}
}
// We're at the end of the internal buffer
if (pos >= count) {
int val = read();
if (val == -1) {
throw new IOException
(sm.getString("requestStream.readline.error"));
}
pos = 0;
readStart = 0;
}
if (buf[pos] == SP) {
space = true;
}
requestLine.method[readCount] = (char) buf[pos];
readCount++;
pos++;
}
After reading 1 char in fill() and putting it in the method buffer,
readCount and pos are incremented, so we have pos = 1, count = 1, and
readCount = 1.
Next loop iteration (assuming the method buffer does not need to be grown :
(pos >= count) will be true, since 1 >= 1, which will call another read.
Since we're at the end of the stream, we get the exception (which is correct
since the status line was wrong).
If the last character read was a space, then the loop will exit (and we
won't read an undefined character).
> You will then read the char at buf[1] which still
>is the char from the last buffer (and so quite undefined).
I can't see why. Is my interpretation on what will happen at the next
iteration wrong ?
> You are right. It is quite easy to reimplement a BIS.
Especially since we don't care about marking here.
Remy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
