* Honor parameters order when parsing query and form parameters
When parsing the query or form parameters in Request, the values are stored in a MultiMap. This class extends HashMap which does not preserve the order of insertion so a request with parameters "first=1&second=2" might end up in a map where "second" will come first when iterating on the entry set.
The order is necessary in some case where the request is signed off the body and/or the query parameters. When the order is not preserved, it is impossible to reconstruct the original request sent, unless using the Request::getInputStream which consumes the stream and makes subsequent calls to Request::getParameters to don't return the form parameters which can be misleading. The same behavior applied to query parameters, by using Request::getQueryString, you get the correct order but Request::getParameters will not.
Moreoever, if the application is behind a reverse proxy using Jetty that is proxying using Request::getParameters which consume the request InputStream, it will be completely impossible to reconstruct the original request.
* Added a test with parameter merging
Co-authored-by: Jacques-Etienne Beaudet <jebeaudet@gmail.com>
* Clarify that requestHeaderSize is a cumulative limit
HttpConfiguration documents the requestHeaderSize configuration option
as being a limit on the size of a single request header, but it is in
fact a limit on the cumulative size of all request headers as well as
the request URI. This patch updates the documentation accordingly, and
adds test cases for the HTTP/1.x and HTTP/2 parsers to verify the
behavior.
NB.: the HTTP/3 parser and configuration seem to correctly document this
option as being a global limit on header size.
* Improve requestHeaderSize tests and documentation per review
Signed-off-by: Máté Szabó <mszabo@wikia-inc.com>
* Issue #7277 - Allow `Request.getLocalName()` and `.getLocalPort()` to be overridden (#7316)
* Introduce `HttpConfiguration.setServerAuthority(HostPort)`
to influence `ServletRequest.getServerName()` and `ServletRequest.getServerPort()`
* Introduce `HttpConfiguration.setLocalAddress(SocketAddress)`
to influence `ServletRequest.getLocalName()`, `ServletRequest.getLocalPort()`, and `ServletRequest.getLocalAddr()`
* Correcting Request URI logic on abs-uri without authority
* Adding test cases
Signed-off-by: Joakim Erdfelt <joakim.erdfelt@gmail.com>
* Issue #6973 - Setup Request/Response objects for success with RequestLog
+ Prevents reading of Request body parameters
+ Still allows raw Request.getInputStream() and
Request.getReader() usage
+ Restores committed response status code.
+ Does not rest committed response headers.
+ Adding testcase for post-commit response header
issue. (currently disabled)
+ Remove Request.onRequestLog()
+ Move requestlog calling from HttpChannel to Request.onCompleted
+ address scenario where HttpChannel is null
Signed-off-by: Joakim Erdfelt <joakim.erdfelt@gmail.com>
- Made HttpChannelOverHTTP3.needContent() to look for content if none is immediately available.
- Improved javadocs.
Signed-off-by: Simone Bordet <simone.bordet@gmail.com>
- Made BlockingContentProducer.onContentProducible() idempotent by checking if the input
is unready before releasing the semaphore.
This is necessary because HTTP/3 will call onContentProducible() just after receiving the request,
while other protocols assume that content is producible and only call onContentProducible()
when they read all the available content.
Signed-off-by: Simone Bordet <simone.bordet@gmail.com>
- WebSocket should user server ByteBufferPool if possible
- fix various bugs ByteBufferPool implementations
- add heuristic for maxHeapMemory and maxDirectMemory
- Add dump for ByteBufferPools
- add LogArrayByteBufferPool that does exponential scaling of bucket size.
- ByteBufferPools should default to use maxMemory heuristic
- Add module jetty-bytebufferpool-logarithmic
Signed-off-by: Lachlan Roberts <lachlan@webtide.com>
Co-authored-by: Simone Bordet <simone.bordet@gmail.com>