- web-devel - Haskell.org

haskell memory allocation
by anaaugusto2012＠bol.com.br 25 Sep '19

25 Sep '19

2 2

ToWidget instances for Text and friends
by Andrew Martin 27 Nov '16

27 Nov '16

I have copied the body of this github issue get feedback on this suggestion: https://github.com/yesodweb/yesod/issues/1298 The ToWidget typeclass could be more helpful than it currently is. Notably, there are sensible instances for Text, lazy Text, and text Builder that are not provided. I think that one objection to introducing such classes is that there is a piece of syntax in the shakespeare quasiquoter ^{..} that calls ToWidget on its argument. Adding more instances would allow the end user to feed text into this construct, which might be undesirable. I don't use the quasiquoter for templating, so the downside of it doesn't bother me. The reason I would like these instances is because there are a number of situations where I have to call `toWidget . toHtml` in my code that could be abbreviated to toWidget if these instances were provided. If this change is at odds with the goals of the TH templating, then I wouldn't want to mess that up for people, but if not, I would find these instances useful. I would appreciate any feedback, even if it's just in the form of a +1 or -1 response without any further explanation. -Andrew Martin

2 1

Feedback request: new Yesod development server
by Michael Snoyman 24 Nov '16

24 Nov '16

Hey all, I've just published a blog post describing an (almost total) rewrite of the `yesod devel` server: http://www.yesodweb.com/blog/2016/11/new-yesod-devel-server This new version is not yet released, I'm requesting feedback before doing so. If people can have a look, I'd appreciate it. I'm including the web-devel list, since this new version has very explicit documentation on how to use `yesod devel` with non-Yesod application. Michael

2 2

[ANN] servant 0.5
by Julian Arni 19 Mar '16

19 Mar '16

Dear all, We have just released a new major version (0.5) of the official servant packages: - servant - servant-server - servant-client - servant-docs - servant-foreign - servant-js - servant-cassava - servant-blaze - servant-lucid - servant-mock (servant-js and servant-foreign are being released for the first time. servant-jquery will be deprecated in favour of servant-js) This new version brings quite a number of significant changes. Servant is now faster, more correct, more replete with features, and more consistent. We have a blog post going into more details about the changes: http://haskell-servant.github.io/posts/2016-03-19-servant-0.5-release.html Note also that we have revamped our tutorial, and moved it to readthedocs: http://haskell-servant.readthedocs.org/en/master/ Enjoy the weekend, Julian

1 0

Keep too busy crawlers away from your server
by Henning Thielemann 01 Mar '16

01 Mar '16

I know there are more sophisticated tools for that task, but I wrote a pretty simple program that works for me reliably for several months now. See the attached program. It scans the last 100 KB of a log-file you specify as command-line argument and checks whether certain clients excess allowedAccessesPerSecond. If so, their IPs are written to a blocked-hosts file and are removed from there only 5 days later. The blocked-hosts file in my example is used by arno-iptables-firewall to actually block the IP addresses. I added this program to my crontab: # m h dom mon dow command * * * * * process-log /var/log/http-access.log >>/var/log/http-block.log 2>>/var/log/http-block.err

1 0

HTTP Status with Streaming Request Bodies
by Mark Fine 29 Feb '16

29 Feb '16

I'm running into a problem handling requests with streaming request bodies that fail - using http-client, the failure takes a long time (potentially never) to propagate. Simple code (runnable project here <https://github.com/mfine/streamy>): {-# LANGUAGE OverloadedStrings #-} import Control.Monad import Data.Conduit.Combinators import Network.HTTP.Conduit import System.Environment a :: IO () a = do manager <- newManager tlsManagerSettings request <- parseUrl "http://httpbin.org/status/409" void $ httpLbs request manager b :: IO () b = do manager <- newManager tlsManagerSettings request <- parseUrl "http://httpbin.org/status/409" void $ flip httpLbs manager request { requestBody = requestBodySourceChunked $ repeatM $ return "a" } Running "a" above works as expected (propagating the error immediately). Running "b" has variable results, mostly never propagating the error. Looking at the wire, I can see that the 409 status comes back, but the exception does not propagate. Is there something I can do here to get quicker failure? Thanks! Mark

1 1

path to sendmail
by Jeremy Shaw 09 Feb '16

09 Feb '16

Hello, I have a web application which needs to send mail using sendmail. However, the way the system is configured, sendmail is not in the web server's $PATH. There are two fixes for this -- change the init script so that sendmail is in the $PATH -- or modify the web server so that the admin can set the path to sendmail via the control panel. At first the second option sounds good. But I wonder about the security implications. If someone manages to get the password for the admin control panel -- they could change the path to sendmail to something else -- like `vim` or `gcc` and then somehow craft a message that would place a backdoor on the system. Now, given that the input to the message is going to be a mime message that sounds pretty difficult. But, then again, in December tons of Joomla sites were open to an exploit where a malformed user-agent header allowed hackers to execute arbitrary code. Although in this case I care about sendmail, this is clearly an issue for any web application that depends on external binaries like pandoc, etc. In my use case, I am dealing with a CMS and I assume the poor user doesn't know anything about Haskell, init scripts, ssh, etc. So, allowing the location to be changed via the admin panel makes things easier because it can be adapted to any distribution. (Clearly, I would start by checking the most common locations, but provide an escape hatch for oddballs). But I don't like the idea of providing a potential attack vector. Any thoughts ? - jeremy

4 3

Announcing serversession
by Felipe Lessa 01 Jan '16

01 Jan '16

Hey! These packages have been available for a while but only now I've finally publicly announced their availability. Please see my blog post at http://blog.felipe.lessa.nom.br/?p=153, but feel free to reply back here. Happy New Year! -- Felipe.

1 0

simple library for HTML form generation and processing
by Henning Thielemann 01 Nov '15

01 Nov '15

I like to get your advice about a simple library for web form generation and processing. So far I tried digestive-functors and reform. Both of them are advertised as being good in separating data from view. However, I am interested in one-off forms, that is, form data will always be rendered in one way. Thus I would like to save the efforts to combine data and view after they have been carefully separated. Formerly I have also used autolib-cgi: http://autolat.imn.htwk-leipzig.de/haddock/autolib-cgi-1.2/ It allowed me to generate the form and fetch and validate the data in one (monadic) go. The blaze-markup type MarkupM is a monad anyway, thus it seems to be straight-forward to use the monadic results for the data entered to the form. Is there a library that supports this style of web form handling?

1 0

Re: [web-devel] web-devel Digest, Vol 71, Issue 1
by Julian Arni 26 Oct '15

26 Oct '15

Thanks again for starting the discussion! As I mentioned, for Servant I think it's unlikely we'd completely move away from our current handlers, since we don't want to lose all the type information we have, and don't want to impose such information on others. So I'm hoping the next best thing might be achievable - allowing the new-style handlers to be run directly, and having conversion functions from our current handlers to the new style. I think the first is easy, and the second possible. Since there isn't enough information at the value-level to establish where it is our handlers are getting their arguments from (query string, headers, request body, etc.), we'd need a Proxy argument for the relevant part of the api. Something like: convert :: (CanConvert api x) => Proxy api -> x -> NewHanderM () Where 'convert' would need to walk down the arguments of x and pull arguments from the appropriate places. E.g., if x ~ Int -> Person -> ExceptT ServantErr IO (), and api ~ Header "H" Int :> ReqBody '[JSON] Person -> Post '[] () we'd have 'convert' conceptually doing: convertExceptT $ liftM2 x (parseHeader <$> getHeader "H") (decode <$> getBody), where getHeader and getBody are functions in the new handler monad (/class). (This isn't quite right, since decoding failures need to be handled). Though as I mentioned before, since for servant at least in one direction it'd be a conversion rather than direct usage of the new handler, and since we can already convert any servant handler plus appropriate Proxy into an Application, and can use any Application as a handler, for us it'd be a lot easier to just use Application. As far as I can tell, this is also true in a couple of other frameworks. Indeed, one of the great things about the Application signature, in my opinion, is that it works well both as the signature for an entire Application and for a handler (that gets a modified request). The only problem we've come across with that idea is that the type of failure of the handler is opaque to the outer framework - so e.g., there's no easy way to tell whether re-routing needs to be triggered because the handler failed to match. This, however, would still be a problem in the model mentioned above. Having something like Application, but with return type IO (Either ReroutePlz ResponseReceived), would likely suffice (as would settling on an exception type). On Thu, Oct 22, 2015 at 2:00 PM, <web-devel-request(a)haskell.org> wrote: > Send web-devel mailing list submissions to > web-devel(a)haskell.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.haskell.org/cgi-bin/mailman/listinfo/web-devel > or, via email, send a message with subject or body 'help' to > web-devel-request(a)haskell.org > > You can reach the person managing the list at > web-devel-owner(a)haskell.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of web-devel digest..." > > > Today's Topics: > > 1. More collaboration in web development (Michael Snoyman) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 22 Oct 2015 08:13:31 +0300 > From: Michael Snoyman <michael(a)snoyman.com> > To: web-devel <web-devel(a)haskell.org>, haskell-wai(a)googlegroups.com, > "yesodweb(a)googlegroups.com" <yesodweb(a)googlegroups.com> > Subject: [web-devel] More collaboration in web development > Message-ID: > <CAKA2JgLpqbOiHVY+vH4vdtUjvY7O-Mb7e2x+ms=B1b= > NFqA-+g(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > I originally kicked this off as an email to the maintainers of some of the > other WAI web frameworks. After some initial brainstorming and some broad > consensus to find some more shared common ground, we decided to open this > up to a broader discussion. > > I think the primary forum for this discussion will likely be the web-devel > mailing list, though I'm cross-posting to haskell-wai and yesodweb as well > for those interested. Please feel free to share with other mailing lists > also. (We debated whether to use web-devel or haskell-wai for this > discussion and didn't come to a decision, I'm fine moving it elsewhere.) > > Based on the discussion, it seems like our best next step will be putting > together a package containing some form of a Handler monad that could be > shared by multiple web frameworks, hopefully making it easier to write code > that can move between various frameworks. By contrast, we also seem to be > in agreement that the high level routing code will end up being > framework-specific, though we may be able to share some common low-level > Trie-based dispatch code. > > I'll leave it to other participants to restate points they made in the > initial private discussion. > > * * * > > Hi all, > > When I was in San Francisco a few months ago, Greg and I discussed the > state of Haskell web development. It's clear that there's a lot of great > stuff going on. Both of us have a strong desire to find as much common > ground for all web framework authors to work on as possible, without > detracting from meaningful distinctions between the various frameworks. > > Greg and I have discussed this point off and on for the past few months, > and haven't come up with very many concrete ideas. The recent work on > http-api-data[1] would be one possible example of collaboration. Other > possible ideas that Greg and I brainstormed were some kind of shared > library for efficient dispatch (that could be used under the surface for > the various high-level interface different libraries already provide), or > some kind of a common Handler-like monad (which from what I've seen many > people seem to reimplement all over the place). Some concrete benefits we > can see from this: > > * Previously, Persistent users were complaining that their types did not > serialize in servant. http-api-data addresses this. > * A common Handler would allow a higher layer abstraction for web apps, > much like WAI provides at a low level. With something like that, sharing > code like authentication logic becomes a reality > * We already have precedence for other such shared libraries: > client-session, server-session, cookie, and authenticate, as a few > examples. > > These are just ideas to kick off some thoughts, I'm sure some discussion > could bring out some better ideas. Overall, it seems like we have a lot of > opportunity to improve the situation for everyone if we focus on such > collaboration. Having a shared low-level HTTP interface (WAI) has already > helped this out considerably, I'm hoping there's something else we can do > in this vein as well. > > Michael > > [1] http://hackage.haskell.org/package/http-api-data >

2 5