* Fixed a bug where TooLongFrameException is not raised immediately when the large frame was fully decoded at the first attempt
* Fixed a bug where LengthFieldBasedFrameDecoder does not reset its state completely after raising TooLongFrameException
ChunkedWriteHandler.discard() do not issue write requests to trigger exceptionCaught events and to notify write futures anymore. Instead, it triggers exceptionCaught events and notifies write futures by itself. Therefore, no write lock is involved during discard(), avoiding the reported dead lock.
However, this is a temporary solution, and eventually Netty must introduce more robust event thread model.
* Reverted back the workaround for servers that sends unnecessary zero-byte chunk in a HEAD response because it actually breaks the codec when the server that conforms to the RFC.
* Fixed a bug in SslHandler where a write attempt made after SSLEngine is closed result in unnotified future. Fixed by respecting the case where SslEngineResult.Status == CLOSED
calling encode(). Without the fix, it ended up in calling the
exception "java.lang.StringIndexOutOfBoundsException".
* Also added test case to verify the patch
Change-Id: Ib96425e07ab50be027ade7be0748cceb6438a586
* Added get/setDateHeader() methods that works with custom date
headers
* Removed get/setDateInMilliseconds() methods because they can be
simply represented with a chained getTime() call
* Fixed the inconsistent behavior & contract of
HttpHeaders.getContentLength() which does not throw an exception when
the header is missing or ill-formatted unless a default value is
specified
* Added clearHeaders() and removeHeader() to HttpHeaders
* Tabs to spaces
* Merged CookieDateFormat into HttpHeaderDateFormat, which can parse all
known date format variants related with HTTP
* Added HttpHeaders.get/setDate()
concurrently initialized and destroyed
* Made ReadTimeoutHandler @Sharable
* Updated the UptimeClient again
** no static fields for global state - just reuse the handlers.
Query string parameters need to be decoded as per RFC 3986, Section 2.
The implementation of the URLDecoder in the JDK is slow because it takes
long and inefficient code paths, and it generates a lot more garbage
than necessary. This decoder is about 2x faster and doesn't allocate
any memory in the easy case where the decoded string is unchanged.
When the string needs to be changed, only one buffer is allocated for
the decoded string.
