Different behaviour with maxFormContentSize=0 if Content-Length header is present/missing

[gbu-censhare]

Hi,

with jetty 9.4.19 some visitors cannot post on our website anymore whe HTTP 2 is in use.
from our tests it works fine as long as a "content-length" header is supplied. if this header is missing it is still working with HTTP 1.1, but not with HTTP 2

it seems the the inputstream of UrlEncoded.decodeUtf8To reads some bytes if HTTP 2 is used but not in HTTP 1.1.

this breaks as soon as HttpServletRequest.getParameters() is called.

if i interpreted the RFCs right the content-length header is not required.

curl 'https://localhost/' -H 'Content-Length:' -H 'Connection: keep-alive' -H 'Cache-Control: max-age=0' -H 'Content-Type: application/x-www-form-urlencoded' --data 'login=user&password=pass' --compressed -D - -q -o /dev/null --http1.1

curl 'https://localhost/' -H 'content-length:' -H 'upgrade-insecure-requests: 1' -H 'content-type: application/x-www-form-urlencoded' --data 'login=login&password=pass'  -D- -q -o /dev/null --http2```

Thanks,
Georg

[gregw]

See point 6 in RFC7230 3.3.3, I think this indicates that if you want to have content in a request, then you need a content-length header (or a transfer encoding). Are you sure that without a content-length that Curl is not chunk encoding the message body? Can you show us the full headers of a request that fails?

[gbu-censhare]

Hi Greg,

6. If this is a request message and none of the above are true, then
   the message body length is zero (no message body is present).

okay, i can get that, so the parameters or not parsed, then, but why is the Body-InputStream checked against this then, and throw a "Form too large"?

HTTP2:

* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x7fd681807a00)
> POST /en HTTP/2
> Host: localhost
> User-Agent: curl/7.54.0
> Accept: */*
> upgrade-insecure-requests: 1
> content-type: application/x-www-form-urlencoded
>
} [25 bytes data]
* We are completely uploaded and fine
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
100    25    0     0  100    25      0      7  0:00:03  0:00:03 --:--:--     7< HTTP/2 400
< x-cs-request-id: a40f2f91-7610-4053-a632-1a33d25b9ef3
< cache-control: must-revalidate,no-cache,no-store
< content-type: text/html;charset=iso-8859-1

HTTP1.1:

> POST /en HTTP/1.1
> Host: localhost
> User-Agent: curl/7.54.0
> Accept: */*
> Content-Type: application/x-www-form-urlencoded
>
} [25 bytes data]
* upload completely sent off: 25 out of 25 bytes
100    25    0     0  100    25      0     11  0:00:02  0:00:02 --:--:--    11< HTTP/1.1 200 OK
< Date: Mon, 08 Jul 2019 09:17:53 GMT
< X-Cs-Request-Id: b7e1e912-1d78-4dcc-9ded-b34d8e1e43f6
< X-Cs-Location: /en
< X-Cs-RequestUrl: https://localhost/
< Cache-Control: no-cache, no-store, must-revalidate
< Pragma: no-cache
< Expires: Thu, 01 Jan 1970 00:00:00 GMT
< Accept-Ranges: bytes
< Vary: Accept-Encoding
< Content-Type: text/html;charset=utf-8
< Content-Length: 114316

Thanks, Georg

[gregw]

Georg,

So without a content-length, HTTP/1.1 should conclude that there is no body to the request. This risk here is that any data sent as the body of the request will then be interpreted as the next request on the connection.
For HTTP/2, it has a better framing mechanism, so it actually knows there is a body... just not what length it is.... so perhaps it is trying to read the data... but then no idea why it would fail to read it properly.

In short, send content-length. But we will investigate what we are doing if there is no content-length. @sbordet thoughts?

[gbu-censhare]

@gregw thanks, so far!

[sbordet]

@gregw yes this behavior looks strange, so needs investigation.

[sbordet]

I cannot reproduce, as it always works for me.

I am using curl 7.64.0.

At this point we need an exact way to reproduce, including the server side. The error 400 that you get may be due to something else.

[gbu-censhare]

i'll try to do wrap it in a test case, is there a good point / example where to put in the jetty code?

[sbordet]

Please zip it and attach it here.

[gbu-censhare]

http2-max-form-size-test-master.zip

it seems to be connected to how we initialize the jetty ServletContextHandler, in our default the _maxFormContentSize/_maxFormKeys is set to 0

and it behaves the same in http1.1/http2 i'm bit puzzeled, why i had this different behavior ...

but i would expect, if maxFormContentSize = 0, the form is still to large if the content-length is set ....

[sbordet]

@gbu-censhare with your reproducer project, I can see the same behavior for HTTP/1.1 and HTTP/2, but a different behavior depending on whether the Content-Length is present or not.

So we'll make sure the behavior is consistent with regards to Content-Length, but it's not about HTTP/1.1 vs HTTP/2.
Are we on the same page?

[gbu-censhare]

Yes, please, i don't know why i misinterpreted in the first place

and thanks :)

[sbordet]

@gbu-censhare can you please build and try branch jetty-9.4.x-3856-maxForm_contentLength_behavior and see if it works for you?

[gbu-censhare]

@sbordet thanks, looks good to me!