February 2014 - web-devel

http2
by Kazu Yamamoto 21 Nov '14

21 Nov '14

Hi guys, I would like to announce the first release of the http2 package. http://hackage.haskell.org/package/http2 This package tries to implement the coming HTTP/2.0. HTTP/2.0 is being standardized in two internet-drafts: http://tools.ietf.org/html/draft-ietf-httpbis-http2-09 http://tools.ietf.org/html/draft-ietf-httpbis-header-compression-05 The current version of the http2 library implements the latter (called HPACK) only at this moment. I would like to make this library so that other HTTP libraries can use when supporting HTTP/2.0. Feedback is welcome. --Kazu

7 15

Re: [web-devel] Upgrading to warp 2
by Bardur Arantsson 26 Feb '14

26 Feb '14

On 2014-02-25 05:49, Michael Snoyman wrote: > On Mon, Feb 24, 2014 at 11:00 PM, Bardur Arantsson <spam(a)scientician.net>wrote: (I've taken the liberty of CC'ing the list.) > >> Hi all, >> [--snip--] >> When I try this I get: >> >> src/Handlers.hs:96:54: >> No instance for (MonadResource IO) >> arising from a use of `sourceFileRange' >> Possible fix: add an instance declaration for (MonadResource IO) >> In the second argument of `($)', namely >> `sourceFileRange sfp (Just l') (Just n)' >> In the expression: >> mapOutput (Chunk . fromByteString) >> $ sourceFileRange sfp (Just l') (Just n) >> In an equation for `src': >> src >> = mapOutput (Chunk . fromByteString) >> $ sourceFileRange sfp (Just l') (Just n) >> >> ... which I guess kinda makes sense -- you'd need a ResourceT (or >> similar) in the monad stack. I'm just not sure how or where to introduce >> the ResourceT to get this working. >> >> If I introduce an explicit type signature for "src", >> >> src :: forall m . MonadResource m => Source m (Flush Builder) >> >> then that line compiles, but I get the equivalent error at the usage >> site of "src" in the third argument to "responseSource" (which again >> also makes sense). >> >> Anyone got any pointers? >> >> Regards, >> >> > Firstly, why aren't you just using responseFile[1]? That will be more > efficient than using a Source directly, since Warp is able to use the > sendfile system call, not to mention all of Kazu's fancy fd-caching logic. > Even on a non-Warp backend, the functionality can simply degrade to being > the same as using a Source. Also, not sure if it's relevant, but Warp can > automatically handle range requests for you, so if you simply return a > responseFile and the user requests part of the file, Warp will > automatically generate the 206 response. > ResponseFile is broken for some clients (with Linux host at least), specifically my type of client, a PlayStation 3 (UPnP media player). There was a Thread of Doom(TM) about it on haskell-cafe, but it caused FD leaks, though we never found out quite *why* it was broken that way. (Things may have changed since this was in February 2010, but frankly I don't even care to spend the time to find out -- I don't need the performance anyway. I think I remember testing the WAI/Warp sendfile equivalent in pre-2.0 WAI/Warp and finding that it still had the same problem.) > Anyway, the issue here is that in WAI 2.0, we removed ResourceT from the > WAI stack for efficiency reasons. Yup, I noticed that ;) > That makes the cases where you *do* need > to safely allocate scarce resources like a file handle a bit trickier. In > this case, I wouldn't bother with ResourceT at all, but instead explicitly > use the bracket pattern, via responseSourceBracket, openFile, and > closeFile. This would look like: > > serveFile :: Integer -> [(Maybe Integer, Maybe Integer)] -> IO Response > serveFile fsz [(l,h)] = do > let l' = maybe 0 id l > let h' = maybe (fsz-1) id h > let n = (h' - l' + 1) > let src h = mapOutput (Chunk . fromByteString) $ sourceHandleRange h > (Just l') (Just n) > sfp = "foo.hs" > responseSourceBracket > (IO.openFile sfp IO.ReadMode) (IO.hClose) $ \h -> > return (partialContent206, [], src h) > > > [1] > http://hackage.haskell.org/package/wai-2.0.0/docs/Network-Wai.html#v:respon… > Ah, yes, this works! I had noticed responseSourceBracket, but (stupidly) didn't actually try it. Thank you very much. Regards,

2 1

Upgrading to warp 2
by Bardur Arantsson 25 Feb '14

25 Feb '14

Hi all, So I decided to upgrade one of my programs to Warp 2.x, but I'm getting stuck on generating the Response from a "sourceFileRange" (from Data.Conduit.Binary). Here's a snippet of the relevant code: serveFile :: Integer -> [(Maybe Integer, Maybe Integer)] -> IO Response serveFile fsz [(l,h)] = do let l' = maybe 0 id l let h' = maybe (fsz-1) id h let n = (h' - l' + 1) let src = mapOutput (Chunk . fromByteString) $ sourceFileRange sfp (Just l') (Just n) return $ responseSource partialContent206 [ hdrContentLength n , (hContentType, mimeType) , hdrContentRange l' h' fsz , hdrAcceptRangesBytes , hdrConnectionClose ] src When I try this I get: src/Handlers.hs:96:54: No instance for (MonadResource IO) arising from a use of `sourceFileRange' Possible fix: add an instance declaration for (MonadResource IO) In the second argument of `($)', namely `sourceFileRange sfp (Just l') (Just n)' In the expression: mapOutput (Chunk . fromByteString) $ sourceFileRange sfp (Just l') (Just n) In an equation for `src': src = mapOutput (Chunk . fromByteString) $ sourceFileRange sfp (Just l') (Just n) ... which I guess kinda makes sense -- you'd need a ResourceT (or similar) in the monad stack. I'm just not sure how or where to introduce the ResourceT to get this working. If I introduce an explicit type signature for "src", src :: forall m . MonadResource m => Source m (Flush Builder) then that line compiles, but I get the equivalent error at the usage site of "src" in the third argument to "responseSource" (which again also makes sense). Anyone got any pointers? Regards,

1 0

Add session header to response of Wai.Application.Static.staticApp
by Leif Warner 17 Feb '14

17 Feb '14

I want to add a session cookie header to the response of staticApp. Now, I know that adding a "session" to a static file doesn't make sense. I just figured I'd set the session once on the splash page, rather than risk generating multiple sessions for the subsequently fetched "dynamic" resources. (They're actually static files, but per-user copies of the static files.) I was maybe hoping for something along the lines of: do response <- (staticApp $ defaultWebAppSettings ".") request return $ response { responseHeaders = sessionCookie : responseHeaders response } But that will tell me "`responseHeaders' is not a record selector". staticApp returns either ResponseFile, or ResponseBuilder (304 "Not Modified"). I could import Network.Wai.Internal, pattern match on those, and return those w/ the added header. That seems a bit crufty, though - was hoping someone could suggest a more elegant solution? Maybe some Lens or Functor instance across a response's headers, I dunno. -Leif

1 1