Snap Framework: What's new this week?
Hi all,
Since we put out the Snap framework last weekend, we’ve been working like busy beavers on squashing correctness and performance bugs. Updated haddocks/etc should be up on our website by tomorrow afternoon. Here’s a short list of the changes in Snap this week:
WINDOWS SUPPORT thanks to Jacob Stanley (a.k.a. “jystic”).
A fix for a grave performance bug with
Transfer-encoding: chunked
; we weren’t buffering its input, causing lots of tiny http transfer chunks for certain pathological input, ruining performance. (This is the one Michael Snoyman reported btw.) Switching to buffering its input increased performance on this test by at least an order of magnitude.Huge improvements to the
libev
backend forsnap-server
, including fixing a correctness/hang bug and an edge-/level-triggering issue. Performance should be improved to the point where thelibev
backend should be considered the “go-to” setup for productionsnap-server
deployments.Improved timeout handling in the “simple”/stock haskell
snap-server
backend. This costs us some performance on the stock backend, but correctness is more important (and users wanting maximum performance should stick with thelibev
backend).Fixed an
attoparsec-iteratee
bug that resulted in spurious “parser did not produce a value” messages clutteringerror.log
.Fixed a localtime/GMT timezone bug which prevented static files from being recognized as “not modified.”
Fixed an HTTP cookie reading bug in
snap-server
.Killed several space leaks.
Fixes to the way Snap handles
accept-encoding
headers in the GZip code — requests from Konqueror and Links are no longer incorrectly rejected.The
snap
command-line tool now has an option to not depend on heist.Exposed error logging to the
Snap
monad...and a whole host of smaller additions/improvements….
Comments
blog comments powered by Disqus