Details
Description
Hi, everybody
My servlet reads POSTed data using a ServletInputStream calling the method in.read(byte b[], int off, int len).
It works fine when len > 0. When len = 0 the stream actually "goes back" for one byte. Next call to read method will return the last read byte again. Javadoc for InputStream says it shouldn't read any bytes and should return 0.
I've searched the source code and found:
class: org.mortbay.io.AbstractBuffer
public int get(byte[] b, int offset, int length)
{ int gi = getIndex(); int l=length(); if (length>l) length=l; length = peek(gi, b, offset, length); setGetIndex(gi + length); return length; } As I understand the code: if length equals 0 method peek returns -1 and the the current index will be se to setGetIndex(gi-1).
I've found two "peek" implementations in org.mortbay.io.nio.NIOBuffer and org.mortbay.io.ByteArrayBuffer and both
return -1 when the given length equals 0.
Example (the code below worked fine in Jetty 4.x and 5.x):
POSTed data contains an 8 byte header, an additional xml header and some binary data.
Simple data example: 00000020<header>...</header>BINARYBINARYBINARY...
Code example:
// read the 8 byte header (contains xml header's length)
byte[] headerLength = new byte[8];
int read = 0;
int readAll = 0;
// last method call will be in.read(headerLength,8,0).
// This last call will "rollback" the stream for one byte.
while ((read=in.read(headerLength,readAll,8-readAll))>0) readAll += read;
// parse fixed header to int
int len = Integer.parseInt(new String(headerLength));
// read the xml header
byte[] header = new byte[len];
read = 0;
readAll = 0;
// the same problem with "rollback" happens here
while ((read=in.read(header,readAll,len-readAll))>0) readAll += read;
// parse xml header
parseHeader(new String(header));
Output in Jetty 4.x or 5.x :
headerLength = 00000020
header = <header>...</header>
Output in Jetty 6.x :
headerLength = 00000020
header = 0<header>...</header
I've already made a simple workaround in the code above, but the bug is actually preventing our company from upgrading our production servers to Jetty 6.x.
regards,
Mitja
ps,
great Java server btw ![]()
Mitja,
Thanks for this bug report. I've fixed this in trunk (rev 2715) and in the 6.1 branch (rev 2716).
regards
Jan