- web-devel - Haskell.org

wai and warp for conduit
by Kazu Yamamoto 13 Jan '12

13 Jan '12

Hello, I come back to my reverse proxy work today. But I could not find wai and warp repository (or branch) based on conduit. Where can I find them? --Kazu

4 10

Implementing SPDY
by Robin Brandt 10 Jan '12

10 Jan '12

Hello there, I'm currently looking into implementing the SPDY [1] protocol based on Warp. I read in the archives that Daniel Sommermann wanted to start something similar for snap-server but I haven't seen any updates for some time. So if you've got a finished implementation somewhere in your drawer this would be a great time to publish it ;) Otherwise I'd start with the parser for the framing layer. SPDY compresses some parts of the frames using zlib. Michael already merged a small patch I wrote into zlib-bindings to support initial dictionaries so I think I'm ready to go there. Another thing that is needed to fully support SPDY is TLS. I think I'd use the tls library by Vincent here. There is some implementation work needed in the library for an extension called NPN (next protocol negotiation) which SPDY uses. Vincent offered to help here. Thanks :) (By the way, although it's possible to force at least Chrome to use non-encrypted connections "it'll break all sorts of things" according to the SPDY book [2]). With this post I'd like to start a discussion about the implementation and interfaces of this so the result can be reused in other contexts (e.g. for Snap). If you've got any suggestions and sources of inspiration I'm happy to hear them. Best regards, Robin [1] http://dev.chromium.org/spdy [2] http://spdybook.com/

3 3

[ANNOUNCE] First release of crypto-conduit
by Felipe Almeida Lessa 08 Jan '12

08 Jan '12

Hello! I'm pleased to announce the first release of crypto-conduit [1]! The crypto-api [2] package provides APIs for many cryptographic operations, such as cryptographic hashes and block ciphers. This new crypto-conduit package allows you to use many of these operations with conduits [3], giving you safe I/O using constant memory and no leaks. As an example, here's how you could get the SHA1 hash a file: import Crypto.Conduit -- from crypto-conduit import Crypto.Hash.SHA1 (SHA1) -- from cryptohash import Data.Conduit -- from conduit import Data.Conduit.Binary (sourceFile) -- from conduit main = do hash <- runResourceT $ sourceFile "my-file" $$ sinkHash print (hash :: SHA1) The code snippet above, despite having only "sourceFile ... $$ sinkHash" on its core, guarantees that the file handle is not kept open and uses a constant amount of memory. Sweet! Please break this package! Although it comes with a test suite, it has just seen the light of the day. Cheers, =) [1] http://hackage.haskell.org/package/crypto-conduit [2] http://hackage.haskell.org/package/crypto-api [3] http://hackage.haskell.org/package/conduit -- Felipe.

5 13

Re: [web-devel] [Haskell-cafe] [ANNOUNCE] First release of crypto-conduit
by Aristid Breitkreuz 08 Jan '12

08 Jan '12

To use the hash, I have to convert it to a ByteString, and then I suddenly have lost all this safety. I don't really see how there is any real safety gained. That said, just exposing a direct method of getting to that ByteString without cereal (as Thomas proposed) would be an improvement. Aristid 2012/1/8 Vincent Hanquez <tab(a)snarc.org>: > On 01/08/2012 04:12 AM, Aristid Breitkreuz wrote: >> >> Why? I don't actually need the hash object for anything, usually. All >> I need is the ByteString, and then I need to learn how to use the >> cereal package to get it... > > The whole rationale i believe, is having meaningful types associated to your > values so that the type checker can do its job. i.e. you don't start mixing > a hash (in binary form) and a random piece of file. > > My only problem with the Serialize instance, is that dependencies (cereal in > this case) trickle through to the user of the API, which would be solved by > Thomas' suggestion. > > -- > Vincent

1 0

Re: [web-devel] [Haskell-cafe] [ANNOUNCE] First release of crypto-conduit
by Aristid Breitkreuz 07 Jan '12

07 Jan '12

2012/1/8 Vincent Hanquez <tab(a)snarc.org>: > What would you prefer ? > > At the moment, i'm inclined to someday move cryptohash apis to be similar to > crypto-api. i.e. from a result type being a bytestring to an opaque type > with serialize/show instance. > Why? I don't actually need the hash object for anything, usually. All I need is the ByteString, and then I need to learn how to use the cereal package to get it... So talking purely about convenience, I would prefer hash :: HashType -> InputData -> ByteString. That would probably not be extensible enough, so I'm not sure how to optimally do it. Aristid

1 0

limiting POST
by Kazu Yamamoto 07 Jan '12

07 Jan '12

Hello guys, As you may know, "Denial of Service through hash table multi-collisions" was disclosed: http://permalink.gmane.org/gmane.comp.security.full-disclosure/83694 The hashable package is affected but not affected to Yesod suite. However, I guess we should provide size limitation of HTTP body on POST to Warp. # Of course, we should provide rate limiting, too. --Kazu

4 5

Re: [web-devel] [Haskell-cafe] [ANNOUNCE] First release of crypto-conduit
by Aristid Breitkreuz 07 Jan '12

07 Jan '12

Yeah and that's annoying IMHO. :) It's not really important though. Aristid Am 07.01.2012 15:39 schrieb "Felipe Almeida Lessa" <felipe.lessa(a)gmail.com>:

1 0

I just published a Wai+Persistent integration testing library (github, not hackage)
by Nubis 03 Jan '12

03 Jan '12

Hi guys, somewhat related to my stupid question yesterday, I finished cleaning up and packing the integration tests library we are using with Max Cantor at Hachicode. https://github.com/nubis/TestWaiPersistent It's based on wai-test. Test cases keep the state of cookies and the last response in order to make assertions on it. It also lets you introspect the last response in order to build your next request, looking up the _nonce and field names of the last received form.It also lets you query the database to pre-populate data and check that your actions get reflected on the database as expected. It's pretty early stage, but already useful, I'd like to hear your opinions about it. As you may notice the source is cabalized but I don't have a username for hackage yet, and even if I had I think I'd wait a bit before publishing it there. PS: While we're at it, I also published a game library a few weeks ago, I'd love feedback on that too: https://github.com/nubis/Monono cheers ----nubis :)

1 0

wai-test, does it accept multipart/form-data too?
by Nubis 03 Jan '12

03 Jan '12

Hi guys, I'm building a yesod testing tool, in part building on top of wai-test for interacting with the yesod application. But I'm noticing that sending multipart/form-data requests using wai-test is not working. url-encoded requests are working as expected, both get and post. The symptom I'm seeing is that both the result of lookupPostParams and lookupFiles for the parameter I'm sending return empty lists. I dug through wai, wai-extra, and yesod handler code and as it seems, yesod's code should be taking care of using wai-extra.parse to get the FileInfo's. I don't want to bother you with the details yet, but I just wanted to know if this is a 'known limitation' of wai-test. More specifically, given this function: srequest :: SRequest -> Session SResponse srequest (SRequest req bod) = do app <- ask res <- liftIO $ run_ $ enumList 4 (L.toChunks bod) $$ app req sres <- liftIO $ runResponse res return sres If 'app' is the wai Application (gotten through toWaiApp), and that app works well with url-encoded. And bod is a lazy char8 bytestring containing a well formed multi-part request body, then my yesod handler should end up having the file data available? right? Also, are there any tests you recommend I do to figure what's going wrong? I can alternatively just publish this testing library/framework now with the broken functionality so you can fork it from github. cheers! ----nubis :)

1 1

Escaping of (') in blaze-html
by Jasper Van der Jeugt 18 Dec '11

18 Dec '11

Hello all, A proposed change to blaze-html came up. In order to make the best decision, I'd like to ask the advice of this list. Currently, the blaze-html library escapes a single quote (') to '. John MacFarlane brought up [1] the fact that this character doesn't need to be excaped in theory. This would have two advantages: - Easier readable output - Saves a few bytes, hence, faster Why doesn't blaze-html need to escape (')? According to the standards, (') only needs to be escaped when it appears inside an attribute value, because something like: a ! href "'content..." could be rendered to <a href ='' content...' and an end-user might be able to inject malicious content. However, blaze-html *always* uses double quotes for attribute values. This means that the previous example would be safely rendered to <a href ="' content..." On the other hand, most sources [2] recommend escaping the (') character, and perhaps it's better to be safe than sorry. Any opinions on this case? [1]: https://github.com/jaspervdj/blaze-html/pull/48 [2]: https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_C… Cheers, Jasper

2 1