* Fixes#5057 Included root context path
Root context path in include should be empty string.
* Issue #5057
merged context path methods as result of review.
ServletContent.getContextPath now returns the encoded contextPath (if anybody is silly enough to have one).
Replace uses of Random with SecureRandom.
We do not believe any of these uses of Random represent any security vulnerability, but we are making this
change for an abundance of caution and to avoid warnings from 3rd party scanning tools.
Fixed MaxConcurrentStreamsTest - it was always broken.
The problem was that the call to super.onSettings(...) was done
_after_ sending the request, so the connection pool was still
configured with the default maxMultiplex=1024.
Also fixed AbstractConnectionPool to avoid a second call to
activate() if we are not trying to create a new connection.
Signed-off-by: Simone Bordet <simone.bordet@gmail.com>
Fixed MultiplexConnectionPool.acquire() to use the new boolean
parameter to decide whether or not create a new connection.
This fixes ConnectionPoolTest instability.
Signed-off-by: Simone Bordet <simone.bordet@gmail.com>
Fixes#4971 - Simplify Connection.upgradeFrom()/upgradeTo().
Now the upgrade-from connection produces a "floating" buffer
(not belonging to a pool), so that it can release the original buffer.
The upgrade-to connection is free to copy or store this "floating" buffer.
Strengthened ByteBufferPool behavior when releasing non-pooled
ByteBuffers: the buffer is now discarded.
Updated javadocs and all implementations.
Signed-off-by: Simone Bordet <simone.bordet@gmail.com>
Fixes#4967 - Possible buffer corruption in HTTP/2 session failures
Partially reverted the changes introduced in #4855, because they
were working only when sends were synchronous.
Introduced ByteBufferPool.remove(ByteBuffer) to fix the issue.
Now when a concurrent failure happens while frames are being
generated or sent, the buffer is discarded instead of being
recycled, therefore resolving the buffer corruption.
Signed-off-by: Simone Bordet <simone.bordet@gmail.com>
Fixes#4976 HttpClient async content throws NPE in DEBUG log.
Reworked handling of asynchronous content by immediately exiting
HttpReceiverOverHTTP.process(), so that there is no race with
other threads that have been scheduled to resume the processing.
The call to HttpReceiver.dispose() that could be triggered by
an asynchronous failure is now performed either by the failing
thread (if the HttpReceiver is not processing) or by an I/O
thread (if the HttpReceiver is processing) similarly to what
happens when terminating the response.
The content decoding has been reworked to perform the required
state changes similarly to what non-decoded content is doing,
as this was completely lacking before (it was actually a side
bug that is now fixed).
Signed-off-by: Simone Bordet <simone.bordet@gmail.com>
Co-authored-by: Ludovic Orban <lorban@bitronix.be>
