Bug in B6361557

Sat Jan 11 18:15:17 UTC 2025

One other point on this, I don’t think the claim that it is compliant is correct.

From section 3.5 https://datatracker.ietf.org/doc/html/rfc7230#section-3.5 it is clear that a client must send a body that matches the content-length, or use a proper chunked encoding.

This language becomes even more clear in the final specification https://www.rfc-editor.org/rfc/rfc9112.html#section-6.2

If provided, the content-length must match the message body, from section 8.6 https://www.rfc-editor.org/rfc/rfc9110#section-8.6

"The "Content-Length" header field indicates the associated representation's data length as a decimal non-negative integer number of octets. When transferring a representation as content, Content-Length refers specifically to the amount of data enclosed so that it can be used to delimit framing (e.g., Section 6.2 of [HTTP/1.1]).”

If you do not properly frame the messages, it would be a security violation for many servers, and the connection should be terminated. Since the subsequent message on that connection will not be valid, it should

“When a server listening only for HTTP request messages, or processing
what appears from the start-line to be an HTTP request message,
receives a sequence of octets that does not match the HTTP-message
grammar aside from the robustness exceptions listed above, the server
SHOULD respond with a 400 (Bad Request) response.”

so in this case, the nulls would be an invalid request line.

> On Jan 6, 2025, at 8:17 AM, robert engels <rengels at ix.netcom.com> wrote:
> 
> And to clarify on what brought me to this, many servers implement http pipelining. Being able to detect that the request has more data after it (ie another request) allows the server to be far more efficient. Sending garbage after the request body will break that optimization. 
> 
>> On Jan 6, 2025, at 8:14 AM, Robert Engels <rengels at ix.netcom.com> wrote:
>> 
>> But then I think http keep alive will break as the next request on that connection will be corrupted and hopefully rejected by the server.
>> 
>> My point was that the test is not sending invalid requests intentionally and that sending invalid requests - unless specifically testing for this - should be avoided. In this case it is 0s but it could easily be a partial http header left over in a reused buffer.
>> 
>> There should be a test that the server properly parses and rejects these requests but this is not that test.
>> 
>>> On Jan 6, 2025, at 8:07 AM, Mark Sheppard <mark.sheppard at oracle.com> wrote:
>>> 
>>> I think there is a misinterpretation of the HTTP spec here.
>>> 
>>> A server is not a User Agent.
>>> The GET request is delimited by the Content-Length: 0 and the two blank line (<CR><LF> <CR><LF>) , such that a server would not look for a request body
>>> For the request in the test, anything after the blanks line are ignored or treated as the start of a separate request.
>>> 
>>> Instrumenting the test's HttpHandler handle method will show that the InputStream associated with the RequestBody return -1, indicating no request body contents.
>>> This is what would be expected
>>> 
>>> So while the change is reasonable, the rationale for it is dubious i.e. the interpreted semantics from
>>> 
>>> "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 latter part of this statement refers to a user agent's processing of a response
>>> ________________________________________
>>> From: net-dev <net-dev-retn at openjdk.org> on behalf of Robert Engels <rengels at ix.netcom.com>
>>> Sent: 06 January 2025 12:10
>>> To: Jaikiran Pai
>>> Cc: net-dev at openjdk.org
>>> Subject: Re: Bug in B6361557
>>> 
>>> Hi,
>>> 
>>> I saw that too. But if you take that stance, if you change the test to send more than one request per connection it will now fail. I think the refreshed rfcs are impossible to implement and it’s an oversight.
>>> 
>>>>> On Jan 6, 2025, at 12:25 AM, Jaikiran Pai <jai.forums2013 at gmail.com> wrote:
>>>> 
>>>> I've now raised a PR to address the test issue. As for the following part:
>>>> 
>>>>>> On 03/01/25 9:11 pm, robert engels wrote:
>>>>> ...
>>>>> 
>>>>> 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."
>>>>> 
>>>>> ...
>>>>> 
>>>>> It currently passes, only because the server is not fully implementing the http specification.
>>>> 
>>>> I read that section again today and (like you note) it states that "HTTP/1.1 user agents MUST notify the user when an invalid length is received and detected."  However, RFC-2616 (the one quoted above) is obsoleted by RFC-9110. RFC-9110 no longer has that above sentence for the Content-Length semantics in section 8.6 (https://www.rfc-editor.org/rfc/rfc9110#name-content-length). Furthermore, RFC-9110 section 3.5 (https://www.rfc-editor.org/rfc/rfc9110#name-user-agents), defines an user agent as:
>>>> 
>>>> "The term "user agent" refers to any of the various client programs that initiate a request."
>>>> 
>>>> So, given all this, I don't think the JDK's current implementation of the HttpServer is in violation of the RFC.
>>>> 
>>>> -Jaikiran
>>>> 
>>>> 
>>>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/net-dev/attachments/20250111/d2cc2864/attachment-0001.htm>