* Issue #5605 unconsumed input on sendError
Add Connection:close if content can't be consumed during a sendError. Processed after the request has returned to the container.
Signed-off-by: Greg Wilkins <gregw@webtide.com>
* Update from review
+ Add close on all uncommitted requests when content cannot be consumed.
* Update from review
+ fixed comment
+ space comma
* Only consume input in COMPLETE if response is >=200 (ie not an upgrade or similar)
* Updated to be less adventurous
I do not think it was valid to always consumeAll in COMPLETE as this could break upgrades with both 101s and 200s
Instead I have reverted to having this consumeAll logic only:
+ in sendError once control has passed back to the container and we are about to generate an error page.
+ in front of all the sendRedirection that we do without calling the application first.
Extra tests also added
* Updated to be less adventurous
reverted test
* Testcase for odd sendError(400) issue.
Signed-off-by: Joakim Erdfelt <joakim.erdfelt@gmail.com>
* Fix for odd sendError(400) issue.
Signed-off-by: Simone Bordet <simone.bordet@gmail.com>
* Testcase for odd sendError(400) issue.
Signed-off-by: Joakim Erdfelt <joakim.erdfelt@gmail.com>
* Always try to consumeAll on all requests
* Refinements after testing in 10
* Refinements after testing in 10
Fixed test
* Fixed comment from review
* Updates from review
+ added redirect methods that consumeAll
+ ensureContentConsumedOrConnectionClose renamed to ensureConsumeAllOrNotPersistent
+ ensureConsumeAllOrNotPersistent now handles HTTP/1.0 and HTTP/1.1 differently
* better consumeAll implementation
* update from review
+ better javadoc
+ filter out keep-alive
+ added more tests
* update from review
+ better javadoc
* update from review
+ fixed form redirection test for http 1.0 and 1.1
* update from review
+ HttpGenerator removes keep-alive if close present
+ Use isRedirection
Co-authored-by: Joakim Erdfelt <joakim.erdfelt@gmail.com>
Co-authored-by: Simone Bordet <simone.bordet@gmail.com>
* Fix#5562 Improve HTTP Field cache allocation
Fix#5562 by initially putting cacheable fields into a inexpensive arraylist.
Only create the Trie (with space and complexity costs) if a second request is received.
* Fixed NPE
* Feedback from review
Create `HttpHeader.isPseudo()`` method
improved clarity with `createFieldCacheIfNeeded()``
* Feedback from review
Only defer Trie creation to first cacheable field, not until next request.
* Updates from review
* Update from review
+ more javadoc
+ empty set return
+ Added all IANA methods
+ Used Trie for most lookups
+ Fixed ArrayTernayTrie lookup
+ optimised GET, POST and HEAD
Co-authored-by: Joakim Erdfelt <joakim.erdfelt@gmail.com>
+ Moved testcase to jetty-http (better place for it)
+ Introduced simplified path spec to aid in sorting
+ Made .getMatches(String) return sorted list by best match.
Signed-off-by: Joakim Erdfelt <joakim.erdfelt@gmail.com>
Signed-off-by: Ludovic Orban <lorban@bitronix.be>
If a null name (or HttpHeader or HttpField) is used
it should throw an ISE
+ .add() should remain consistent
+ .put() should remain consistent
Signed-off-by: Joakim Erdfelt <joakim.erdfelt@gmail.com>
Updates after review.
Now the Content-Length header is generated by HpackEncoder based on
MetaData.contentLength, so that the MetaData.HttpFields are not modified.
Signed-off-by: Simone Bordet <simone.bordet@gmail.com>
* Fixes#4542 Root pathspec mapping pathInfo
For the "" root pathspec, the pathinfo should always be the full path and the matched path is ""
Signed-off-by: Greg Wilkins <gregw@webtide.com>
* updates from review
Signed-off-by: Greg Wilkins <gregw@webtide.com>
Changed the way the test directory was created: it was based on a
millisecond timestamp, but the tests run fast and it was possible that
two tests were creating the directory within the same millisecond.
Signed-off-by: Simone Bordet <simone.bordet@gmail.com>
Fix#4541 by initially allocated a header buffer of `min(_config.getResponseHeaderSize(), _config.getOutputBufferSize())`
Only allocate a buffer of `getResponseHeaderSize` if an overflow results.
This should have no effect on the majority of responses where `getOutputBufferSize` is greater than `getResponseHeaderSize` other than the cost of a min operation.
Signed-off-by: Greg Wilkins <gregw@webtide.com>
Greg Wilkins
Joakim Erdfelt
Simone Bordet
Jan Bartel
Lachlan Roberts
Ludovic Orban
olivier lamy