- web-devel - Haskell.org

Tutorial for creating haskell apps in the browser easy
by Alberto G. Corona 05 Nov '14

05 Nov '14

Hi Just in case you don´t noticed it, this is the first tutorial for creating Browser applications in Haskell for non haskellers. http://www.airpair.com/haskell/posts/haskell-tutorial-introduction-to-web-a… -- Alberto.

1 1

New mailing list: haskell-wai
by Michael Snoyman 07 Oct '14

07 Oct '14

After some discussion[1] on a Github issue, it became apparent that a number of people using WAI[2] could definitely benefit from having a shared discussion area. One obvious area of collaboration is discussing more efficient route dispatch algorithms, but there are likely many other topics worth discussing. Since none of the existing mailing lists seem appropriate for this, I've created a new mailing list: https://groups.google.com/d/forum/haskell-wai If you're using WAI- especially using it to write a web framework or coding applications directly against it, but even just indirectly via an existing framework- I'd highly recommend you join the discussion. [1] https://github.com/philopon/apiary-benchmark/pull/2 [2] http://hackage.haskell.org/package/wai

1 0

Yesod + email auth
by Karsten Gebbert 17 Sep '14

17 Sep '14

Hi List, I'm seeing a somewhat unexpected behaviour using Yesod.Auth.Email. What I'm doing is this: I enter a password into the form, but no email, and the login handler redirects me to /auth/page/email/login which seems to use the default layout (I specified a separate layout for auth) and does not render the login form. I can't see a method that lets me override where the user is sent on unsuccessful login, and judging from reading the sources I should be sent the LoginR way. Any idea what I could be doing wrong here? Thanks all, Karsten

2 2

Finding the redirected-to URL in http-client?
by Michael Alan Dorman 13 Aug '14

13 Aug '14

I appreciate http-client's ability to automatically handle redirections for me---even chained ones. However, I cannot seem to find a way to retrieve out what the terminal URL was---the information is presumably available within the data structures http-client uses (since there are a couple of HttpExceptions that effectively expose it), but I don't see any way to get to it through the public API. MIke.

1 0

ANNOUNCE: hplayground: haskell client-side web framework
by Alberto G. Corona 25 Jul '14

25 Jul '14

hplayground [1] is a haskell framework that compiles to JavaScript with the haste [5] compiler. It handles reactive effects under a applicative-monad that controls the modifications of the user interface. It is quite easy to create dynamic, composable applications using ordinary, beatiful, idiomatic haskell without special constructions. Rather than a framework, it is an EDSL. Full reinversion of control avoid spagetty event handlers and the monad confines the events and their effects to the subtree where they appear avoiding the problems of declarative reactive frameworks. There are examples running[4] the source code is in [1] And there is a todo reference application [3] running [2] too. There is also a blog post about that[7] Additionally, the syntax is almost identical to the formlet widgets in MFlow[6]. So most of the hplaygroud code could run also in a server if javascript is disabled. But MFlow and hplayground are completely independent projects. I hope that you enjoy it as much as I enjoyed the development of it. A big thanks to Anton Ekblad for his wonderful Haste compiler. [1] https://github.com/agocorona/hplayground [2] http://mflowdemo.herokuapp.com/todo.html [3] https://github.com/agocorona/hplay-todo [4] http://mflowdemo.herokuapp.com/noscript/wiki/browserwidgets [5] http://http://haste-lang.org/ [6] http://hackage.haskell.org/package/MFlow [7] http://haskell-web.blogspot.com.es/2014/07/hplayground-translate-your-conso… -- Alberto.

1 0

Re: [web-devel] [Haskell] ANNOUNCE: haste-perch
by Alberto G. Corona 18 Jun '14

18 Jun '14

The syntax is similar to blaze-html, but haste-perch uses the HTM-DOM in the browser to create DOM elements. blaze-html creates a html bytestring in the server that the browser must load. It uses Haste.DOM http://hackage.haskell.org/package/haste-compiler-0.2.99/docs/Haste-DOM.html Haste.DOM has primitives that invoke Javascript functions in browser like: For example newElem invoke "createElement" in javascript Perch assemble a sequence of DOM calls that create the HTML tree directly in the browser. so you can create an application that run fully in the browser The tree can change depeding on different actions done by the user by changing the HTML tree dynamically. It is possible to create dynamic applications. 2014-06-18 18:11 GMT+02:00 Andrew Gibiansky <andrew.gibiansky(a)gmail.com>: > Could you elaborate on how this is better/different from blaze-html? > > I'm a bit confused - is it just the same thing but works with Haste, while > blaze-html doesn't? What's the main idea? > > Thanks! > Andrew > > > On Wed, Jun 18, 2014 at 7:02 AM, Alberto G. Corona <agocorona(a)gmail.com> > wrote: > >> Hi, >> >> haste-perch defines builder elements (perchs) for Haste.DOM elements that >> are appendable, so that dynamic HTML can be created in the client in a >> natural way, like textual HTML, but programmatically and with the advantage >> of static type checking. It can be ported to other haskell-js compilers. >> >> http://hackage.haskell.org/package/haste-perch >> >> This program, when compiled with haste: >> >> main= do >> withElem "idelem" $ build $ do >> div $ do >> div $ do >> p "hello" >> p ! atr "style" "color:red" $ "world" >> >> return () >> >> Creates these element: >> >> <div id= "idelem"> <-- was already in the HTML >> <div> >> <div> >> <p> hello </p> >> <p style= "color:red"> world </p> >> </div> >> </div> >> </div> >> >> Since the creation is in the browser, that permit quite dynamic pages for >> data >> presentation, and interctive textual (a.k.a "serious") applications and, >> in general >> the development of client-side web frameworks using haskell with the >> haste compiler. >> >> >> See the README in the git repository: >> >> https://github.com/agocorona/haste-perch >> >> -- >> Alberto. >> >> _______________________________________________ >> Haskell mailing list >> Haskell(a)haskell.org >> http://www.haskell.org/mailman/listinfo/haskell >> >> > -- Alberto.

1 1

ANNOUNCE: haste-perch
by Alberto G. Corona 18 Jun '14

18 Jun '14

Hi, haste-perch defines builder elements (perchs) for Haste.DOM elements that are appendable, so that dynamic HTML can be created in the client in a natural way, like textual HTML, but programmatically and with the advantage of static type checking. It can be ported to other haskell-js compilers. http://hackage.haskell.org/package/haste-perch This program, when compiled with haste: main= do withElem "idelem" $ build $ do div $ do div $ do p "hello" p ! atr "style" "color:red" $ "world" return () Creates these element: <div id= "idelem"> <-- was already in the HTML <div> <div> <p> hello </p> <p style= "color:red"> world </p> </div> </div> </div> Since the creation is in the browser, that permit quite dynamic pages for data presentation, and interctive textual (a.k.a "serious") applications and, in general the development of client-side web frameworks using haskell with the haste compiler. See the README in the git repository: https://github.com/agocorona/haste-perch -- Alberto.

1 0

WAI 3.0
by Michael Snoyman 05 May '14

05 May '14

A few weeks ago, I wrote a blog post about a proposal for WAI 3.0, which would no longer be based on conduit, and therefore be open to various streaming data frameworks. The response I've received so far has been (I think universally) positive, and therefore I'd like to move forward. There was a good discussion on Reddit[1], but I think the mailing list is a better way to come to consensus on a last few points. In particular, there are two questions still up in the air: 1. Twan raised the question[2] of how to deal with the streaming response body. We need the ability to either emit a new Builder, or flush the stream. I believe we have three different interfaces available to choose from: a. (Maybe Builder -> IO ()) -> IO () b. (Builder -> IO ()) -> IO () -> IO () c. data ResponseStream = ResponseStream { responseStreamPart :: Builder -> IO () , responseStreamFlush :: IO () } ResponseStream -> IO () (a) is probably the simplest, but also likely to be the least efficient. I tend towards choosing (b), since it avoids the need for an extra datatype, but (c) looks cleaner overall. 2. Dan[3] and Stephen[4] both raised issues about how we'd deal with scarce resource allocation when creating a streaming response. Here's a summary: a. The approach I linked to in the blog came down to the bracket pattern. The downsides of this are (i) a poorly behaving application could call the callback multiple times, and (ii) it complicates the interface. b. To avoid problem (i), we could use something like the Acquire datatype[5], making the type signature `type Application = Request -> Acquire Response`. I'm overall negative on this, as the goal here is to continue simplifying to standard datatypes. c. Stephen's suggestion is to include a cleanup action in the ResponseStream constructor. My primary concern here is that it will be very difficult for application authors to write async-exception-safe code, vs option (a) which makes it trivial. On both of these questions, new ideas are certainly welcome. Michael [1] http://www.reddit.com/r/haskell/comments/246e39/disemboweling_wai_aka_gutti… [2] http://www.reddit.com/r/haskell/comments/246e39/disemboweling_wai_aka_gutti… [3] http://www.reddit.com/r/haskell/comments/246e39/disemboweling_wai_aka_gutti… [4] http://www.reddit.com/r/haskell/comments/246e39/disemboweling_wai_aka_gutti… [5] http://hackage.haskell.org/package/resourcet-1.1.2/docs/Data-Acquire.html

1 0

ANN: uhttpc - Minimal HTTP client library optimized for benchmarking
by Herbert Valerio Riedel 29 Apr '14

29 Apr '14

Hello web-devel, (sorry if you get this twice, I originally sent this from an unsubscribed email address) Even though I already announced this on reddit[1], I was reminded by one of the comments this special-interest-group list exists, and therefore I'd like to point your attention to http://hackage.haskell.org/package/uhttpc which (as was pointed out by one reddit commenter) can be regarded as the client-side of acme-http. I've been able to get comparable measurements to what weighttp and ab reports against HTTP servers such as nginx, but I've noticed some sub-optimal results when using only a single kept-alive connection. For instance, on my i7-3770 Linux desktop against an nginx server I get: ,---- | $ uhttpc-bench -n 200000 -t1 -c2 -k http://localhost/ | uhttpc-bench - a Haskell-based ab/weighttp-style webserver benchmarking tool | | starting benchmark... | finished in 15.024069 seconds, 200000 reqs (1 conns), 13312.0 req/s received | status codes: 200000 HTTP-200 | data received: 11153.977 KiB/s, 171600000 bytes total (49200000 bytes http + 122400000 bytes content) | rtt min/avg/max = 0.038/0.074/9.928 ms `---- vs. ,---- | $ uhttpc-bench -n 200000 -t1 -c2 -k http://localhost/ | uhttpc-bench - a Haskell-based ab/weighttp-style webserver benchmarking tool | | starting benchmark... | finished in 4.849609 seconds, 200000 reqs (2 conns), 41240.4 req/s received | status codes: 200000 HTTP-200 | data received: 34554.976 KiB/s, 171600000 bytes total (49200000 bytes http + 122400000 bytes content) | rtt min/avg/max = 0.031/0.048/7.207 ms `---- Whereas running `weighttp` with -c1 vs -c2 gives a linear 1x factor scaling of 20k req/s vs 40k req/s (as opposed to the 1.5x factor scaling of uhttpc-bench between -c1 and -c2) Therefore, uhttpc-bench is significantly worse than weighttp when using only a single connection. I can't explain that yet. [1]: http://www.reddit.com/r/haskell/comments/23yuvs/%C2%B5http_lowlevel_http_cl…

2 1

Re: [web-devel] XSS vs charset
by Michael Snoyman 02 Apr '14

02 Apr '14

On Wed, Apr 2, 2014 at 9:08 AM, Kazu Yamamoto <kazu(a)iij.ad.jp> wrote: > Hi Michael, > > Thank you for your reply. > > > I suppose theoretically you could be talking about a situation where > Mighty > > is hosting a CGI application that receives user data and produces a > static > > HTML file as a result. > > Yes. Also I'm thinking about Yesod. > > Yesod has more of a focus on dynamic content, and in those cases, we *do* already set charset=utf8[1]. Where this would affect Yesod is in yesod-static, in which case the same logic I've applied to Mighty would apply: users should not be able to affect the content of static files under normal circumstances, so the security concern is pretty remote. [1] https://github.com/yesodweb/yesod/blob/master/yesod-core/Yesod/Core/Content… > > But it > > could be worked around by the CGI application using <meta charset=...> > > instead. > > Yes. Is this rarely used in Yesod? > > Yes. Dynamic responses don't normally go via static file serving at all. In WAI terms, we always end up with a ResponseBuilder, not a ResponseFile, for dynamic content. > > So that comes to the question: is it safe for Mighty, mime-types, etc, to > > require that all HTML files are stored as UTF-8? I'd say, as long as > > there's a way for a user to override that if necessary, it sounds good to > > me. mime-types does provide such a capability, so I'd be in favor of > > tweaking its textual types to include explicit charset information. > > Probably I was too sensitive. Based on your discussion, it is > safer/better for Mighty not to hard-code charset. > > To be clear, besides the security concerns, there is *definitely* a usability advantage in specifying charsets explicitly, in that the browser doesn't need to use defaults or guessing[2]. This just comes down to a numbers game: is it more likely that a browser will mis-guess the character encoding of UTF8 data, or that someone running Mighty will provide non-UTF8 data? One other point in the favor of specifying encoding type is that serving of a file will *reliably* fail. Without a charset, some browsers may guess the wrong character encoding while others won't, which makes it difficult to debug. If you *always* serve with charset=utf8 and that turns out to be wrong, you'll find out quickly and reliably. [2] http://en.wikipedia.org/wiki/Charset_detection

2 3