
On Tue, Jun 14, 2011 at 11:50 AM, Michael Snoyman
I think the reason we didn't include the header is because, when I wrote it, I didn't know of a cross-platform way to get file sizes. Now that I know about unix-compat, this seems like a reasonable thing to add. Anyone know a reason we *shouldn't* do this?
In Lift, we do not automatically populate the Content-Length for generic BLOB responses because if the response is streaming, then we have to strictly evaluate the stream to determine the length. For returning large items (e.g., a 2 GB AVI), this can cause issues. We break the Response types into "In Memory" which are strict and we include the Content-Length header, but for responses that are not strict, it's up to the coder. My 2 cents.
Michael
Hi guys, Just wanted to give you a heads up that yesod's sendFile is not setting
Content-Length header, which 'breaks' some proxies and load balancers. (in our case, amazon elastic load balancer). I don't know if that's by design, I'm not 100% sure but not setting the header would be only useful for 'long pooling' of binary files for doing some sort of hackish http streaming, which I don't think is yesod's
anyways :) A workaround is setting the Content-Length header before calling sendFile, I guess it may be something easy to add, I was going to propose a patch
On Tue, Jun 14, 2011 at 8:16 PM, Nubis
wrote: the purpose that just wraps the current implementation in a do block that sets the header, but then I noticed a number of optimizations being made that hint there should be a 'better' way.
cheers! ----nubis :)
_______________________________________________ web-devel mailing list web-devel@haskell.org http://www.haskell.org/mailman/listinfo/web-devel
_______________________________________________ web-devel mailing list web-devel@haskell.org http://www.haskell.org/mailman/listinfo/web-devel
-- Lift, the simply functional web framework http://liftweb.net Simply Lift http://simply.liftweb.net Follow me: http://twitter.com/dpp Blog: http://goodstuff.im