Bug in B6361557

Robert Engels rengels at ix.netcom.com
Sat Jan 4 04:26:43 UTC 2025


Thanks!

> On Jan 3, 2025, at 6:52 PM, Jaikiran Pai <jai.forums2013 at 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


More information about the net-dev mailing list