-
Bug
-
Resolution: Fixed
-
P4
-
8
-
b05
| Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
|---|---|---|---|---|---|---|
| JDK-8351702 | 24-pool | Unassigned | P4 | New | Unresolved | |
| JDK-8351703 | 21-pool-oracle | Unassigned | P4 | New | Unresolved | |
| JDK-8351704 | 17-pool-oracle | Unassigned | P4 | New | Unresolved | |
| JDK-8351705 | 11-pool-oracle | Unassigned | P4 | New | Unresolved | |
| JDK-8351706 | 8-pool | Unassigned | P4 | New | Unresolved |
(From a mail on net-dev mailing list https://mail.openjdk.org/pipermail/net-dev/2025-January/025297.html)
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.
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.
- backported by
-
JDK-8351702 Bug in com/sun/net/httpserver/bugs/B6361557.java test
-
- New
-
-
-
- New
-
-
-
- New
-
-
-
- New
-
-
-
- New
-
- links to
-
Commit(master)
openjdk/jdk/5e6cda47
-
Review(master)
openjdk/jdk/22921
(2 links to)