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 >>> >>> >>>
