Bug in B6361557

[Robert Engels]

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