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 <reng...@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 <reng...@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.shepp...@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-r...@openjdk.org> on behalf of Robert Engels >>> <reng...@ix.netcom.com> >>> Sent: 06 January 2025 12:10 >>> To: Jaikiran Pai >>> Cc: net-dev@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.forums2...@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 >>>> >>>> >>>>
