Thanks!
> On Jan 3, 2025, at 6:52 PM, Jaikiran Pai <jai.forums2...@gmail.com> wrote: > > Hello Robert, > > This does indeed look like an issue in the test. I've filed > https://bugs.openjdk.org/browse/JDK-8347000 to address this. Thank you for > bringing it up here. > > -Jaikiran > >> On 03/01/25 9:11 pm, robert engels wrote: >> Hi, >> >> The jdk test B6361557 here >> https://github.com/openjdk/jdk23u/blob/9101cc14972ce6bdeb966e67bcacc8b693c37d0a/test/jdk/com/sun/net/httpserver/bugs/B6361557.java#L68 >> >> sends an invalid http request according to the specification here >> https://datatracker.ietf.org/doc/html/rfc2616#section-4.4 >> >> specifically "When a Content-Length is given in a message where a >> message-body is >> allowed, its field value MUST exactly match the number of OCTETs in >> the message-body. HTTP/1.1 user agents MUST notify the user when an >> invalid length is received and detected." >> >> The code in this test case sends a request with Content-length set to 0, but >> due to a bug, it sends extra octets after the request header (14 zero to be >> exact). >> >> The cause is that the buffer is allocated to 64, and filled with a string >> that is shorter, but the entire buffer is sent. >> >> This is fixed by changing line 68 to >> >> final static ByteBuffer requestBuf = ByteBuffer.wrap(request.getBytes()); >> >> It currently passes, only because the server is not fully implementing the >> http specification. >> >> —Robert
