- Using http2 v1.5.x which much improves the performance of HTTP/2.
- To get rid of the bottleneck of ByteString’s (==), a new logic to compare header names is introduced.
- Add back
- Major version up due to breaking changes. This is because the HTTP/2 code was started over with Warp 3.1.3 due to performance issue #470.
- runHTTP2, runHTTP2Env, runHTTP2Settings and runHTTP2SettingsSocket were removed from the Network.Wai.Handler.Warp module.
- The performance of HTTP/2 was drastically improved. Now the performance of HTTP/2 is almost the same as that of HTTP/1.1.
- The logic to handle files in HTTP/2 is now identical to that in HTTP/1.1.
- Internal stuff was removed from the Network.Wai.Handler.Warp module according to the plan.
- Setting lower bound for auto-update #495
- Providing a new API: killManager.
- Preventing space leaks due to Weak ThreadId #488
- Setting upper bound for http2.
- Fix: warp-tls strips out the Host request header #478
- Using the new priority queue based on PSQ provided by http2 lib again.
- Using the new priority queue based on PSQ provided by http2 lib.
- A concatenated Cookie header is prepended to the headers to ensure that it flows pseudo headers. #454
- Providing a new settings:
- Adding back http-types 0.8 support #449
- Using newer http2 library to prevent change table size attacks.
- API for HTTP/2 server push and trailers. #426
- Preventing response splitting attacks. #435
- Concatenating multiple Cookie: headers in HTTP/2.
- Warp now supports blaze-builder v0.4 or later only.
- HTTP/2 code was improved: dynamic priority change, efficient queuing and sender loop continuation. #423 #424
- Configurable Slowloris size #418
- Remove dependency on the void package #375
- Turn off file descriptor cache by default #371
- Fix for: HEAD requests returning non-empty entity body #369
- Only conditionally produce HTTP 100 Continue
- Better HEAD support for files #357
- Fix missing
- Disable timeouts as soon as request body is fully consumed. This addresses
the common case of a non-chunked request body. Previously, we would wait
until a zero-length
ByteStringis returned, but that is suboptimal for some cases. For more information, see issue 351.
- Don’t serve a 416 status code for 0-length files keter issue #75
- Don’t serve content-length for 416 responses #346
Fix support for old versions of bytestring
Add support for blaze-builder 0.4
- Add runEnv: like run but uses $PORT #334
Support for PROXY protocol, such as used by Amazon ELB TCP. This is useful since, for example, Amazon ELB HTTP does not have support for Websockets. More information on the protocol is available from Amazon.
Modify flushing of request bodies. Previously, regardless of the size of the request body, the entire body would be flushed. When uploading large files to a web app that does not accept such files (e.g., returns a 413 too large status), browsers would still send the entire request body and the servers will still receive it.
The new behavior is to detect if there is a large amount of data still to be consumed and, if so, immediately terminate the connection. In the case of chunked request bodies, up to a maximum number of bytes is consumed before the connection is terminated.
This is controlled by the new setting
setMaximumBodyFlush. A value of
@Nothing@ will return the original behavior of flushing the entire body.
WAI no longer uses conduit for its streaming interface.
onClose settings now provide the
SockAddr of the client,
onOpen can return a
Bool which will close the connection. The
responseRaw response has been added, which provides a more elegant way to
handle WebSockets than the previous
settingsIntercept. The old settings
accessors have been deprecated in favor of new setters, which will allow
settings changes to be made in the future without breaking backwards
ResourceT is not used anymore. Request and Response is now abstract data types. To use their constructors, Internal module should be imported.
Support for byte range requests.
Sockets now have
FD_CLOEXEC set on them. This behavior is more secure, and
the change should not affect the vast majority of use cases. However, it
appeared that this is buggy and is fixed in 2.0.0.