From cdep.illabout+hweb at gmail.com  Sun Jan  5 06:49:30 2014
From: cdep.illabout+hweb at gmail.com (cdep.illabout+hweb at gmail.com)
Date: Sun, 5 Jan 2014 15:49:30 +0900
Subject: [web-devel] template for happstack project
Message-ID: <CA+VjmF+_GQETPsYwXdvWvw3B4Gb7fmut3-BG0F0=cVfdM6RLow@mail.gmail.com>

I am looking for a good template to use for a happstack project.

I want to write a dynamic site (like a blog or a twitter clone) using
happstack, and I am looking for a project template for a site based on
happstack.

Ideally the template project would include things like:
1) some sort of html templater (like heist? hsx? or even blaze-html?)
2) some sort of javascript [translation?] library (like jmacro or fay)
3) a small example of working with RqData
4) some sort of form library (reform?)
5) type-safe routing (web-routes?)
6) some sort of db-layer (acid-state or persistent)

It would also be nice to see the "recommended" layout for the actual
source files on disk.  For example, how to split source code up in
some fashion (MVC?).

I guess an example project would be just as good as a project
template...  Does anyone know of something like this?

From abimelech at gmail.com  Mon Feb 17 08:37:32 2014
From: abimelech at gmail.com (Leif Warner)
Date: Mon, 17 Feb 2014 00:37:32 -0800
Subject: [web-devel] Add session header to response of
	Wai.Application.Static.staticApp
Message-ID: <CAG2mRG6cji1zbrGM9HS4sT5DXuU5izQZh15VEGXwUMOhgTS3QQ@mail.gmail.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/web-devel/attachments/20140217/2d994bee/attachment.html>

From abimelech at gmail.com  Mon Feb 17 08:40:56 2014
From: abimelech at gmail.com (Leif Warner)
Date: Mon, 17 Feb 2014 00:40:56 -0800
Subject: [web-devel] Add session header to response of
	Wai.Application.Static.staticApp
In-Reply-To: <CAG2mRG6cji1zbrGM9HS4sT5DXuU5izQZh15VEGXwUMOhgTS3QQ@mail.gmail.com>
References: <CAG2mRG6cji1zbrGM9HS4sT5DXuU5izQZh15VEGXwUMOhgTS3QQ@mail.gmail.com>
Message-ID: <CAG2mRG4tQBqvpOuy+H_p-wtCvvFwfvfkMy1YR1gzYadE-4wYMA@mail.gmail.com>

Ah, shoulda checked here first, sorry - there's a "mapHeaders" method in
wai-util:
https://github.com/singpolyma/wai-util/blob/master/Network/Wai/Util.hs#L90


On Mon, Feb 17, 2014 at 12:37 AM, Leif Warner <abimelech at gmail.com> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/web-devel/attachments/20140217/a825e610/attachment.html>

From spam at scientician.net  Mon Feb 24 21:00:07 2014
From: spam at scientician.net (Bardur Arantsson)
Date: Mon, 24 Feb 2014 22:00:07 +0100
Subject: [web-devel] Upgrading to warp 2
Message-ID: <legbs9$ks7$1@ger.gmane.org>

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,


From spam at scientician.net  Tue Feb 25 19:43:15 2014
From: spam at scientician.net (Bardur Arantsson)
Date: Tue, 25 Feb 2014 20:43:15 +0100
Subject: [web-devel] Upgrading to warp 2
In-Reply-To: <CAKA2JgJ48oEYOnOJV2bkj5XDz6uLNmsCd3ue5c8RrwxuybjXfw@mail.gmail.com>
References: <legbs9$ks7$1@ger.gmane.org>
 <CAKA2JgJ48oEYOnOJV2bkj5XDz6uLNmsCd3ue5c8RrwxuybjXfw@mail.gmail.com>
Message-ID: <530CF253.6080102@scientician.net>

On 2014-02-25 05:49, Michael Snoyman wrote:
> On Mon, Feb 24, 2014 at 11:00 PM, Bardur Arantsson <spam at 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:responseFile
> 

Ah, yes, this works! I had noticed responseSourceBracket, but (stupidly)
didn't actually try it. Thank you very much.

Regards,


From tyler.huffman at tylerh.org  Tue Feb 25 21:25:15 2014
From: tyler.huffman at tylerh.org (Tyler Huffman)
Date: Tue, 25 Feb 2014 14:25:15 -0700
Subject: [web-devel] Upgrading to warp 2
In-Reply-To: <530CF253.6080102@scientician.net>
References: <legbs9$ks7$1@ger.gmane.org>
 <CAKA2JgJ48oEYOnOJV2bkj5XDz6uLNmsCd3ue5c8RrwxuybjXfw@mail.gmail.com>
 <530CF253.6080102@scientician.net>
Message-ID: <CAMYb46BB-0ntuHG8+RoSRXR6W+9QWRhdgb9Kk5HA+v32qNHSXA@mail.gmail.com>

Thanks for keeping the mailing list involved. It's pretty quiet, but those
of us that develop on the many Haskell web frameworks highly appreciate it.
=)


Regards,
Tyler Huffman


On Tue, Feb 25, 2014 at 12:43 PM, Bardur Arantsson <spam at scientician.net>wrote:

> On 2014-02-25 05:49, Michael Snoyman wrote:
> > On Mon, Feb 24, 2014 at 11:00 PM, Bardur Arantsson <spam at 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:responseFile
> >
>
> Ah, yes, this works! I had noticed responseSourceBracket, but (stupidly)
> didn't actually try it. Thank you very much.
>
> Regards,
>
> _______________________________________________
> web-devel mailing list
> web-devel at haskell.org
> http://www.haskell.org/mailman/listinfo/web-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/web-devel/attachments/20140225/9de265fc/attachment.html>

From michael at snoyman.com  Wed Mar  5 16:54:53 2014
From: michael at snoyman.com (Michael Snoyman)
Date: Wed, 5 Mar 2014 18:54:53 +0200
Subject: [web-devel] Proposed change to WAI: responseRaw
Message-ID: <CAKA2JgJ3g_UUe98Gq2_TrpfDEchKtX9EZYKM1wD8CXH-Zy6-jw@mail.gmail.com>

I've just tested out a new feature in WAI, which is available for testing
on the raw-response branch[1]. Here's a summary of the change itself and
its purpose. If there are no objections, I'm planning on releasing this as
WAI 2.1.

The goal is to have better support for WebSockets. WAI 2.0 and earlier are
based purely around request/response pairs, without interleaving of reads
and writes. There is some ambiguity about that interleaving when it comes
to streaming responses[1], but essentially, WAI does not currently support
the ability to have bidirectional communications with a client.

The current wai-websockets package ties into a special settings hook
provided by Warp (settingsIntercept). While this works, it makes it
difficult to provide websockets support as a first-class citizen of a web
framework. It also makes creating a WebSockets-aware HTTP reverse proxy
more involved and less efficient.

The proposed change comes down to a single new function in Network.Wai:

responseRaw
    :: (C.Source IO B.ByteString -> C.Sink B.ByteString IO () -> IO ())
    -> Response
    -> Response

This would including a corresponding addition of a ResponseRaw constructor
to Resonse. The idea is that the application would provide a function which
takes a Source of bytes from the client, a Sink for sending bytes to the
client, and the web server would provide that source/sink to the
application. Since not all backends will support responseRaw (e.g., CGI),
there is a requirement for a backup Response to be provided, which will be
used in those cases.

This is a very minor breaking change to the existing API. Only code which
explicitly pattern matches on Response constructors will be affected, and
even there the necessary changes are trivial (see the changes on the
raw-response branch).

Are there any objections to this change, or recommendations for ways to
make it better?

Michael

[1] And in fact, I first tried implementing this change purely using the
existing streaming response interface. However, after attempting it, it
felt like too much of a hack, so I went for the responseRaw approach
instead.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/web-devel/attachments/20140305/71d318e9/attachment.html>

From greg at gregweber.info  Wed Mar  5 19:03:02 2014
From: greg at gregweber.info (Greg Weber)
Date: Wed, 5 Mar 2014 11:03:02 -0800
Subject: [web-devel] Fwd: [Yesod] Proposed change to WAI: responseRaw
In-Reply-To: <CAKA2JgJ3g_UUe98Gq2_TrpfDEchKtX9EZYKM1wD8CXH-Zy6-jw@mail.gmail.com>
References: <CAKA2JgJ3g_UUe98Gq2_TrpfDEchKtX9EZYKM1wD8CXH-Zy6-jw@mail.gmail.com>
Message-ID: <CAKRanNAtfErHv_taAP62fJvAZ9dHNuMMZJ+XYSQxqKxBV8k8FA@mail.gmail.com>

---------- Forwarded message ----------
From: Michael Snoyman <michael at snoyman.com>
Date: Wed, Mar 5, 2014 at 8:54 AM
Subject: [Yesod] Proposed change to WAI: responseRaw
To: web-devel <web-devel at haskell.org>, "yesodweb at googlegroups.com" <
yesodweb at googlegroups.com>, Kazu Yamamoto <kazu at iij.ad.jp>


I've just tested out a new feature in WAI, which is available for testing
on the raw-response branch[1]. Here's a summary of the change itself and
its purpose. If there are no objections, I'm planning on releasing this as
WAI 2.1.

The goal is to have better support for WebSockets. WAI 2.0 and earlier are
based purely around request/response pairs, without interleaving of reads
and writes. There is some ambiguity about that interleaving when it comes
to streaming responses[1], but essentially, WAI does not currently support
the ability to have bidirectional communications with a client.

The current wai-websockets package ties into a special settings hook
provided by Warp (settingsIntercept). While this works, it makes it
difficult to provide websockets support as a first-class citizen of a web
framework. It also makes creating a WebSockets-aware HTTP reverse proxy
more involved and less efficient.

The proposed change comes down to a single new function in Network.Wai:

responseRaw
    :: (C.Source IO B.ByteString -> C.Sink B.ByteString IO () -> IO ())
    -> Response
    -> Response

This would including a corresponding addition of a ResponseRaw constructor
to Resonse. The idea is that the application would provide a function which
takes a Source of bytes from the client, a Sink for sending bytes to the
client, and the web server would provide that source/sink to the
application. Since not all backends will support responseRaw (e.g., CGI),
there is a requirement for a backup Response to be provided, which will be
used in those cases.

This is a very minor breaking change to the existing API. Only code which
explicitly pattern matches on Response constructors will be affected, and
even there the necessary changes are trivial (see the changes on the
raw-response branch).

Are there any objections to this change, or recommendations for ways to
make it better?

Michael

[1] And in fact, I first tried implementing this change purely using the
existing streaming response interface. However, after attempting it, it
felt like too much of a hack, so I went for the responseRaw approach
instead.

-- 
You received this message because you are subscribed to the Google Groups
"Yesod Web Framework" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to yesodweb+unsubscribe at googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/web-devel/attachments/20140305/adbb8368/attachment.html>

From m at jaspervdj.be  Wed Mar  5 19:18:06 2014
From: m at jaspervdj.be (Jasper Van der Jeugt)
Date: Wed, 5 Mar 2014 20:18:06 +0100
Subject: [web-devel] Proposed change to WAI: responseRaw
In-Reply-To: <CAKA2JgJ3g_UUe98Gq2_TrpfDEchKtX9EZYKM1wD8CXH-Zy6-jw@mail.gmail.com>
References: <CAKA2JgJ3g_UUe98Gq2_TrpfDEchKtX9EZYKM1wD8CXH-Zy6-jw@mail.gmail.com>
Message-ID: <20140305191806.GA667@jasper.local>

Great! I always considered `settingsIntercept` a little ad-hoc.  This
sounds like a nice generalisation.

Peace,
Jasper

On Wed, Mar 05, 2014 at 06:54:53PM +0200, Michael Snoyman wrote:
> I've just tested out a new feature in WAI, which is available for testing
> on the raw-response branch[1]. Here's a summary of the change itself and
> its purpose. If there are no objections, I'm planning on releasing this as
> WAI 2.1.
> 
> The goal is to have better support for WebSockets. WAI 2.0 and earlier are
> based purely around request/response pairs, without interleaving of reads
> and writes. There is some ambiguity about that interleaving when it comes
> to streaming responses[1], but essentially, WAI does not currently support
> the ability to have bidirectional communications with a client.
> 
> The current wai-websockets package ties into a special settings hook
> provided by Warp (settingsIntercept). While this works, it makes it
> difficult to provide websockets support as a first-class citizen of a web
> framework. It also makes creating a WebSockets-aware HTTP reverse proxy
> more involved and less efficient.
> 
> The proposed change comes down to a single new function in Network.Wai:
> 
> responseRaw
>     :: (C.Source IO B.ByteString -> C.Sink B.ByteString IO () -> IO ())
>     -> Response
>     -> Response
> 
> This would including a corresponding addition of a ResponseRaw constructor
> to Resonse. The idea is that the application would provide a function which
> takes a Source of bytes from the client, a Sink for sending bytes to the
> client, and the web server would provide that source/sink to the
> application. Since not all backends will support responseRaw (e.g., CGI),
> there is a requirement for a backup Response to be provided, which will be
> used in those cases.
> 
> This is a very minor breaking change to the existing API. Only code which
> explicitly pattern matches on Response constructors will be affected, and
> even there the necessary changes are trivial (see the changes on the
> raw-response branch).
> 
> Are there any objections to this change, or recommendations for ways to
> make it better?
> 
> Michael
> 
> [1] And in fact, I first tried implementing this change purely using the
> existing streaming response interface. However, after attempting it, it
> felt like too much of a hack, so I went for the responseRaw approach
> instead.

> _______________________________________________
> web-devel mailing list
> web-devel at haskell.org
> http://www.haskell.org/mailman/listinfo/web-devel


From michael at snoyman.com  Thu Mar  6 05:22:45 2014
From: michael at snoyman.com (Michael Snoyman)
Date: Thu, 6 Mar 2014 07:22:45 +0200
Subject: [web-devel] Security update: update to warp 2.0.3.3
Message-ID: <CAKA2JgK59JUqLfYuRvofHbxyk9Ru5z+Kx4=5+igGSVPYzO0m9A@mail.gmail.com>

We received a security report yesterday of a regression in the Warp 2.0
series[1] related to Slowloris protection. Please see the issue for
details. The important information is:

* Versions prior to 2.0 are not affected.
* Updating to 2.0.3.3 solves the problem.

Yesod users: I've just released a new version of yesod-platform which
updates the warp dependency.

If there are any questions, please let me know.

[1] https://github.com/yesodweb/wai/issues/231
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/web-devel/attachments/20140306/d990cd89/attachment.html>

From PascalWittmann at gmx.net  Thu Mar  6 13:48:02 2014
From: PascalWittmann at gmx.net (Pascal Wittmann)
Date: Thu, 06 Mar 2014 14:48:02 +0100
Subject: [web-devel] Security update: update to warp 2.0.3.3
In-Reply-To: <CAKA2JgK59JUqLfYuRvofHbxyk9Ru5z+Kx4=5+igGSVPYzO0m9A@mail.gmail.com>
References: <CAKA2JgK59JUqLfYuRvofHbxyk9Ru5z+Kx4=5+igGSVPYzO0m9A@mail.gmail.com>
Message-ID: <53187C92.6060203@gmx.net>

Hi Michael,

On 03/06/2014 06:22 AM, Michael Snoyman wrote:
> We received a security report yesterday of a regression in the Warp 2.0
> series[1] related to Slowloris protection.

thank you for the information, the new version is now in NixOS.

Regards Pascal


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://www.haskell.org/pipermail/web-devel/attachments/20140306/0163382b/attachment.sig>

From kazu at iij.ad.jp  Wed Apr  2 05:02:36 2014
From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=))
Date: Wed, 02 Apr 2014 14:02:36 +0900 (JST)
Subject: [web-devel] XSS vs charset
Message-ID: <20140402.140236.656680455081019843.kazu@iij.ad.jp>

Hi all,

I heard that if an HTTP server does not specify charset for text/html
in HTTP responses, XSS would be possible:

	http://openmya.hacker.jp/hasegawa/security/utf7cs.html

I would like to change Mighty to specify charset=UTF-8. Before that, I
would like to discuss some items on this ML.

- Can we assume that recent contents are written in UTF-8?
  For Japanese community, the answer is probably YES.
- Which components should spcify charset=UTF-8?
  The mime-types package?

--Kazu

From michael at snoyman.com  Wed Apr  2 06:13:18 2014
From: michael at snoyman.com (Michael Snoyman)
Date: Wed, 2 Apr 2014 09:13:18 +0300
Subject: [web-devel] XSS vs charset
In-Reply-To: <CAKA2JgLPD992cNwBewinKLZFf8XcE8sUOpWG2rt2sbGcVX6hMw@mail.gmail.com>
References: <20140402.140236.656680455081019843.kazu@iij.ad.jp>
 <CAKA2JgLPD992cNwBewinKLZFf8XcE8sUOpWG2rt2sbGcVX6hMw@mail.gmail.com>
Message-ID: <CAKA2Jg+SWPUEOjEN6qM5T24CE5fQyWYYHLWi2hGwUzC4HvZEkg@mail.gmail.com>

Forgot to CC the list.


On Wed, Apr 2, 2014 at 8:51 AM, Michael Snoyman <michael at snoyman.com> wrote:

> I'm not sure if Mighty is really vulnerable to this attack. IIUC, you're
> worried about a static file receiving some compromised data from a user
> which includes a UTF-7 sequence. However, Mighty is only serving static
> data files (as opposed to generating HTML from a database query or
> something), so if a user is able to compromise those already, it sounds
> like *nothing* you can do would prevent an attack.
>
> 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. In that case, you would be open to an attack.
> But it could be worked around by the CGI application using <meta
> charset=...> instead.
>
> Putting aside the question of this specific attack for the moment, what
> would be the advantages and disadvantages of forcing charset=utf-8?
>
> * Advantage: if the data is actually UTF-8, the browser will always treat
> it as such. Without such a specification, a browser is free to guess at
> some other character encoding.
> * Disadvantage: if the data isn't actually UTF-8, then the browser will
> have no ability to try to guess the correct encoding instead.
>
> 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.
>
>
> On Wed, Apr 2, 2014 at 8:02 AM, Kazu Yamamoto <kazu at iij.ad.jp> wrote:
>
>> Hi all,
>>
>> I heard that if an HTTP server does not specify charset for text/html
>> in HTTP responses, XSS would be possible:
>>
>>         http://openmya.hacker.jp/hasegawa/security/utf7cs.html
>>
>> I would like to change Mighty to specify charset=UTF-8. Before that, I
>> would like to discuss some items on this ML.
>>
>> - Can we assume that recent contents are written in UTF-8?
>>   For Japanese community, the answer is probably YES.
>> - Which components should spcify charset=UTF-8?
>>   The mime-types package?
>>
>> --Kazu
>> _______________________________________________
>> web-devel mailing list
>> web-devel at haskell.org
>> http://www.haskell.org/mailman/listinfo/web-devel
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/web-devel/attachments/20140402/f47b7af8/attachment.html>

From michael at snoyman.com  Wed Apr  2 06:19:33 2014
From: michael at snoyman.com (Michael Snoyman)
Date: Wed, 2 Apr 2014 09:19:33 +0300
Subject: [web-devel] XSS vs charset
In-Reply-To: <20140402.150800.830021048240973438.kazu@iij.ad.jp>
References: <20140402.140236.656680455081019843.kazu@iij.ad.jp>
 <CAKA2JgLPD992cNwBewinKLZFf8XcE8sUOpWG2rt2sbGcVX6hMw@mail.gmail.com>
 <20140402.150800.830021048240973438.kazu@iij.ad.jp>
Message-ID: <CAKA2JgLgngQw8+2uUHERyPoB3g==KAN_HrEAWMbr8TUv44d2ow@mail.gmail.com>

On Wed, Apr 2, 2014 at 9:08 AM, Kazu Yamamoto <kazu at 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.hs#L161


> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/web-devel/attachments/20140402/afba13a1/attachment.html>

From kazu at iij.ad.jp  Wed Apr  2 06:41:00 2014
From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=))
Date: Wed, 02 Apr 2014 15:41:00 +0900 (JST)
Subject: [web-devel] XSS vs charset
In-Reply-To: <CAKA2JgLgngQw8+2uUHERyPoB3g==KAN_HrEAWMbr8TUv44d2ow@mail.gmail.com>
References: <CAKA2JgLPD992cNwBewinKLZFf8XcE8sUOpWG2rt2sbGcVX6hMw@mail.gmail.com>
 <20140402.150800.830021048240973438.kazu@iij.ad.jp>
 <CAKA2JgLgngQw8+2uUHERyPoB3g==KAN_HrEAWMbr8TUv44d2ow@mail.gmail.com>
Message-ID: <20140402.154100.1198919279200055956.kazu@iij.ad.jp>

> 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.

When I checked Yesod today, it returned text/html without charset. But
it appeared that it was my mistake. Hhat I saw was a 500
response (from Warp, not from Yesod). Sigh.

OK. Yesod returns charset. Good.

> 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?

I'm assuming that static files contains charset information in their
meta header. Creators of static files can do it by themselves without
asking their server operator.

--Kazu

From michael at snoyman.com  Wed Apr  2 07:38:34 2014
From: michael at snoyman.com (Michael Snoyman)
Date: Wed, 2 Apr 2014 10:38:34 +0300
Subject: [web-devel] XSS vs charset
In-Reply-To: <20140402.154100.1198919279200055956.kazu@iij.ad.jp>
References: <CAKA2JgLPD992cNwBewinKLZFf8XcE8sUOpWG2rt2sbGcVX6hMw@mail.gmail.com>
 <20140402.150800.830021048240973438.kazu@iij.ad.jp>
 <CAKA2JgLgngQw8+2uUHERyPoB3g==KAN_HrEAWMbr8TUv44d2ow@mail.gmail.com>
 <20140402.154100.1198919279200055956.kazu@iij.ad.jp>
Message-ID: <CAKA2JgJi-8q61yZFBinmmZNjnY=waq5dk_0QV8YaJcd=D+JPRw@mail.gmail.com>

On Wed, Apr 2, 2014 at 9:41 AM, Kazu Yamamoto <kazu at iij.ad.jp> wrote:

> > 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.
>
> When I checked Yesod today, it returned text/html without charset. But
> it appeared that it was my mistake. Hhat I saw was a 500
> response (from Warp, not from Yesod). Sigh.
>
> OK. Yesod returns charset. Good.
>
>
Good catch on the Warp responses, there's no reason *not* to include
charset on those. I've pushed a commit for that[1].

[1]
https://github.com/yesodweb/wai/commit/1daa65863367251d965be36e5fb388d54681cb0b


> > 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?
>
> I'm assuming that static files contains charset information in their
> meta header. Creators of static files can do it by themselves without
> asking their server operator.
>
>
That's a reasonable assumption. When possible, I still prefer using HTTP
headers, as that would also address CSS and Javascript files. But given the
complexity of needing to add an entire configuration system to Mighty to
allow users to override default character set information, it's probably
not worth making the change. Unless I hear otherwise, I'll leave mime-types
as-is for now.

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/web-devel/attachments/20140402/787b3eee/attachment.html>

From kazu at iij.ad.jp  Thu Apr  3 00:26:30 2014
From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=))
Date: Thu, 03 Apr 2014 09:26:30 +0900 (JST)
Subject: [web-devel] XSS vs charset
In-Reply-To: <CAKA2JgJi-8q61yZFBinmmZNjnY=waq5dk_0QV8YaJcd=D+JPRw@mail.gmail.com>
References: <CAKA2JgLgngQw8+2uUHERyPoB3g==KAN_HrEAWMbr8TUv44d2ow@mail.gmail.com>
 <20140402.154100.1198919279200055956.kazu@iij.ad.jp>
 <CAKA2JgJi-8q61yZFBinmmZNjnY=waq5dk_0QV8YaJcd=D+JPRw@mail.gmail.com>
Message-ID: <20140403.092630.2211470484631335801.kazu@iij.ad.jp>

> Good catch on the Warp responses, there's no reason *not* to include
> charset on those. I've pushed a commit for that[1].
> 
> [1]
> https://github.com/yesodweb/wai/commit/1daa65863367251d965be36e5fb388d54681cb0b

Thanks.

> Unless I hear otherwise, I'll leave mime-types
> as-is for now.

I agree.

--Kazu


From hvr at gnu.org  Sun Apr 27 10:49:35 2014
From: hvr at gnu.org (Herbert Valerio Riedel)
Date: Sun, 27 Apr 2014 12:49:35 +0200
Subject: [web-devel] ANN: uhttpc - Minimal HTTP client library optimized for
	benchmarking
Message-ID: <877g6boxmo.fsf@gmail.com>

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_client_library_for/

From kazu at iij.ad.jp  Wed Apr 30 03:09:08 2014
From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=))
Date: Wed, 30 Apr 2014 12:09:08 +0900 (JST)
Subject: [web-devel] ANN: uhttpc - Minimal HTTP client library optimized
 for benchmarking
In-Reply-To: <877g6boxmo.fsf@gmail.com>
References: <877g6boxmo.fsf@gmail.com>
Message-ID: <20140430.120908.1377604766270919806.kazu@iij.ad.jp>

Hi Herbert,

I have not read the source code of uhttpc. But here are random
thoughts which I want to share with you:

- I had the same experience in the server side. In my case, HTTP
  response header and HTTP response body are sent separately.  Please
  read "Sending the Header and Body Together" in the POSA article.

	http://aosabook.org/en/posa/warp.html

- runInUnboundThread might help. See:

	https://github.com/kazu-yamamoto/witty

  Also, measuring witty by uhttpc would be interesting because
  witty is much faster than acme-http.

- Mio (new IO manager) uses "yield". This would make the response time
  worse. This might be one open issue for Mio. I guess it's worth
  removing "yield" from GHC.Event.Manager and rebuilding GHC to see what
  happens.

--Kazu

> 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_client_library_for/
> _______________________________________________
> web-devel mailing list
> web-devel at haskell.org
> http://www.haskell.org/mailman/listinfo/web-devel

From michael at snoyman.com  Mon May  5 15:43:36 2014
From: michael at snoyman.com (Michael Snoyman)
Date: Mon, 5 May 2014 18:43:36 +0300
Subject: [web-devel] WAI 3.0
Message-ID: <CAKA2Jg+SMr+iHb-_shr-efDP1ZLqr6EOiYpKTJLhGbr7aP4yFw@mail.gmail.com>

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_gutting_out_conduit/
[2]
http://www.reddit.com/r/haskell/comments/246e39/disemboweling_wai_aka_gutting_out_conduit/ch444fr
[3]
http://www.reddit.com/r/haskell/comments/246e39/disemboweling_wai_aka_gutting_out_conduit/ch4cv55
[4]
http://www.reddit.com/r/haskell/comments/246e39/disemboweling_wai_aka_gutting_out_conduit/ch4d88x
[5]
http://hackage.haskell.org/package/resourcet-1.1.2/docs/Data-Acquire.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/web-devel/attachments/20140505/16098ab4/attachment.html>

From agocorona at gmail.com  Wed Jun 18 14:02:11 2014
From: agocorona at gmail.com (Alberto G. Corona )
Date: Wed, 18 Jun 2014 16:02:11 +0200
Subject: [web-devel] ANNOUNCE: haste-perch
Message-ID: <CAArEJmYbG=z8k+JOqh0diruiU2H5ipf6_8Ubx9ha-7nN_80G-w@mail.gmail.com>

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/web-devel/attachments/20140618/3abe7b84/attachment.html>

From agocorona at gmail.com  Wed Jun 18 17:20:09 2014
From: agocorona at gmail.com (Alberto G. Corona )
Date: Wed, 18 Jun 2014 19:20:09 +0200
Subject: [web-devel] [Haskell] ANNOUNCE: haste-perch
In-Reply-To: <CAF-LYKJK3wTcFRXJycOPeDmfKJGvm0G23rWZfbJ+1Wf=wgwrJQ@mail.gmail.com>
References: <CAArEJmYbG=z8k+JOqh0diruiU2H5ipf6_8Ubx9ha-7nN_80G-w@mail.gmail.com>
 <CAF-LYKJK3wTcFRXJycOPeDmfKJGvm0G23rWZfbJ+1Wf=wgwrJQ@mail.gmail.com>
Message-ID: <CAArEJmZoh5A8ZfrvzrtQGY8L9=Nwxi+Hs_KfDN03_VQxg3msVg@mail.gmail.com>

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 at 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 at 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 at haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell
>>
>>
>


-- 
Alberto.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/web-devel/attachments/20140618/0052343d/attachment.html>

From agocorona at gmail.com  Wed Jun 18 17:43:54 2014
From: agocorona at gmail.com (Alberto G. Corona )
Date: Wed, 18 Jun 2014 19:43:54 +0200
Subject: [web-devel] [Haskell] ANNOUNCE: haste-perch
In-Reply-To: <CAArEJmZoh5A8ZfrvzrtQGY8L9=Nwxi+Hs_KfDN03_VQxg3msVg@mail.gmail.com>
References: <CAArEJmYbG=z8k+JOqh0diruiU2H5ipf6_8Ubx9ha-7nN_80G-w@mail.gmail.com>
 <CAF-LYKJK3wTcFRXJycOPeDmfKJGvm0G23rWZfbJ+1Wf=wgwrJQ@mail.gmail.com>
 <CAArEJmZoh5A8ZfrvzrtQGY8L9=Nwxi+Hs_KfDN03_VQxg3msVg@mail.gmail.com>
Message-ID: <CAArEJmbWSSqFjOQNQZJWbJbAPX=CScPiuxayidBRXsCC09aWYw@mail.gmail.com>

The readme in the Git repository tell more details

https://github.com/agocorona/haste-perch/blob/master/README.md

And also this blog post:

http://haskell-web.blogspot.com.es/2014/06/taming-html-dom-with-monads-and-monoids.html


2014-06-18 19:20 GMT+02:00 Alberto G. Corona <agocorona at gmail.com>:

> 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 at 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 at 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 at haskell.org
>>> http://www.haskell.org/mailman/listinfo/haskell
>>>
>>>
>>
>
>
> --
> Alberto.
>



-- 
Alberto.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/web-devel/attachments/20140618/73955597/attachment.html>

From agocorona at gmail.com  Sat Jul 26 01:34:17 2014
From: agocorona at gmail.com (Alberto G. Corona )
Date: Sat, 26 Jul 2014 03:34:17 +0200
Subject: [web-devel] ANNOUNCE: hplayground: haskell client-side web framework
Message-ID: <CAArEJmYNwEH4y6G42-KnvCbenDzpjyq6B1q7=gwCkOiQPRAu0g@mail.gmail.com>

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-console.html

-- 
Alberto.

From mdorman at ironicdesign.com  Wed Aug 13 10:55:31 2014
From: mdorman at ironicdesign.com (Michael Alan Dorman)
Date: Wed, 13 Aug 2014 06:55:31 -0400
Subject: [web-devel] Finding the redirected-to URL in http-client?
Message-ID: <87ha1gzmjg.fsf@ironicdesign.com>

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.

From k at ioctl.it  Wed Sep 17 14:28:45 2014
From: k at ioctl.it (Karsten Gebbert)
Date: Wed, 17 Sep 2014 16:28:45 +0200
Subject: [web-devel] Yesod + email auth
Message-ID: <86bnqegw2q.fsf@fook.fritz.box>

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

From k at ioctl.it  Wed Sep 17 15:25:03 2014
From: k at ioctl.it (Karsten Gebbert)
Date: Wed, 17 Sep 2014 17:25:03 +0200
Subject: [web-devel] Yesod + email auth
In-Reply-To: <86bnqegw2q.fsf@fook.fritz.box>
References: <86bnqegw2q.fsf@fook.fritz.box>
Message-ID: <868uligtgw.fsf@fook.fritz.box>

digging deeper into the source, I found that its basically trying to
re-direct to the parent route, which, in this case is not obvious which
one that is? My guess is that its the PluginR Route, since it matches
the one I'm redirected to.

    https://github.com/yesodweb/yesod/blob/master/yesod-auth/Yesod/Auth/Routes.hs

 
My question would be: is there a standard way of dealing with this kind
of failure that I'm overlooking? Shouldn't the default for unsuccessful
logins be /auth/login ?

Thanks for any pointers,

k

Karsten Gebbert <k at ioctl.it> writes:

> 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
> _______________________________________________
> web-devel mailing list
> web-devel at haskell.org
> http://www.haskell.org/mailman/listinfo/web-devel

From greg at gregweber.info  Wed Sep 17 15:33:12 2014
From: greg at gregweber.info (Greg Weber)
Date: Wed, 17 Sep 2014 08:33:12 -0700
Subject: [web-devel] Yesod + email auth
In-Reply-To: <868uligtgw.fsf@fook.fritz.box>
References: <86bnqegw2q.fsf@fook.fritz.box> <868uligtgw.fsf@fook.fritz.box>
Message-ID: <CAKRanNDCRENN=Fj-yTjob9efXvOYMBJ2YKsEoDTqdVzO+sENuw@mail.gmail.com>

Hi Karsten,

I personally use the JSON API which gives me complete control over the flow.

First make sure you are using the latest version of yesod-auth.
If you are still having a problem with the layout that gets rendered then
that could be a bug.
With respect to where the login redirect that is probably also something
that should be changed.

So you should either
* open an issue on the github issues for yesodweb about the login redirect
* send this message to the yesodweb email list.

web-devel is supposed to be for things such as WAI that work across
frameworks.

Thanks,
Greg Weber

On Wed, Sep 17, 2014 at 8:25 AM, Karsten Gebbert <k at ioctl.it> wrote:

> digging deeper into the source, I found that its basically trying to
> re-direct to the parent route, which, in this case is not obvious which
> one that is? My guess is that its the PluginR Route, since it matches
> the one I'm redirected to.
>
>
> https://github.com/yesodweb/yesod/blob/master/yesod-auth/Yesod/Auth/Routes.hs
>
>
> My question would be: is there a standard way of dealing with this kind
> of failure that I'm overlooking? Shouldn't the default for unsuccessful
> logins be /auth/login ?
>
> Thanks for any pointers,
>
> k
>
> Karsten Gebbert <k at ioctl.it> writes:
>
> > 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
> > _______________________________________________
> > web-devel mailing list
> > web-devel at haskell.org
> > http://www.haskell.org/mailman/listinfo/web-devel
> _______________________________________________
> web-devel mailing list
> web-devel at haskell.org
> http://www.haskell.org/mailman/listinfo/web-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/web-devel/attachments/20140917/c1dce3a9/attachment.html>

From michael at snoyman.com  Tue Oct  7 08:21:00 2014
From: michael at snoyman.com (Michael Snoyman)
Date: Tue, 7 Oct 2014 11:21:00 +0300
Subject: [web-devel] New mailing list: haskell-wai
Message-ID: <CAKA2JgLh5+fOjNOvCok0zvNmeAy5q22s5wpVKsG6DE8tqg8Uwg@mail.gmail.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/web-devel/attachments/20141007/4b7da8ab/attachment.html>

From agocorona at gmail.com  Tue Nov  4 22:49:28 2014
From: agocorona at gmail.com (Alberto G. Corona )
Date: Tue, 4 Nov 2014 23:49:28 +0100
Subject: [web-devel] Tutorial for creating haskell apps in the browser easy
Message-ID: <CAArEJmZTRJ8uT6FQOcX8LFYKiZ6wEdLXKdRsVO9gLtW-qRv=Jg@mail.gmail.com>

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-apps

-- 
Alberto.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/web-devel/attachments/20141104/dfad1188/attachment.html>

From agocorona at gmail.com  Wed Nov  5 09:47:35 2014
From: agocorona at gmail.com (Alberto G. Corona )
Date: Wed, 5 Nov 2014 10:47:35 +0100
Subject: [web-devel] Tutorial for creating haskell apps in the browser
	easy
In-Reply-To: <CAArEJmZTRJ8uT6FQOcX8LFYKiZ6wEdLXKdRsVO9gLtW-qRv=Jg@mail.gmail.com>
References: <CAArEJmZTRJ8uT6FQOcX8LFYKiZ6wEdLXKdRsVO9gLtW-qRv=Jg@mail.gmail.com>
Message-ID: <CAArEJmaBW3QSb=69QFMbJT+MBJSSZFbt3BPf30UOhBKbUyoKcw@mail.gmail.com>

I feel like Prometheus, the semi-god that teach humans how to make fire, a
privilege of the gods.

Will I receive the wrath of the gods of Category Theory for revealing the
secret? There will be an industrial Hercules?

2014-11-04 23:49 GMT+01:00 Alberto G. Corona <agocorona at gmail.com>:

> 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-apps
>
> --
> Alberto.
>



-- 
Alberto.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/web-devel/attachments/20141105/ebb5dd9a/attachment.html>

From agocorona at gmail.com  Wed Nov  5 18:50:44 2014
From: agocorona at gmail.com (Alberto G. Corona )
Date: Wed, 5 Nov 2014 19:50:44 +0100
Subject: [web-devel] [Haskell-cafe] Tutorial for creating haskell apps
	in the browser easy
In-Reply-To: <op.xouthiskpz0j5l@alquantor>
References: <CAArEJmZTRJ8uT6FQOcX8LFYKiZ6wEdLXKdRsVO9gLtW-qRv=Jg@mail.gmail.com>
 <CAArEJmaBW3QSb=69QFMbJT+MBJSSZFbt3BPf30UOhBKbUyoKcw@mail.gmail.com>
 <op.xouthiskpz0j5l@alquantor>
Message-ID: <CAArEJmZDMJBrSiAvrquH134j_=051hXsnRPeXg1NLvc-X8vq3A@mail.gmail.com>

They are eating my brain already!

2014-11-05 14:37 GMT+01:00 Henk-Jan van Tuyl <hjgtuyl at chello.nl>:

>
> There is a good chance that you will be punished for eternity, that your
> liver will be eaten daily by a monad.
>
>
> On Wed, 05 Nov 2014 10:47:35 +0100, Alberto G. Corona  <
> agocorona at gmail.com> wrote:
>
>  I feel like Prometheus, the semi-god that teach humans how to make fire, a
>> privilege of the gods.
>>
>> Will I receive the wrath of the gods of Category Theory for revealing the
>> secret? There will be an industrial Hercules?
>>
>> 2014-11-04 23:49 GMT+01:00 Alberto G. Corona <agocorona at gmail.com>:
>>
>>  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-apps
>>>
>>> --
>>> Alberto.
>>>
>>>
> --
> Folding at home
> What if you could share your unused computer power to help find a cure? In
> just 5 minutes you can join the world's biggest networked computer and get
> us closer sooner. Watch the video.
> http://folding.stanford.edu/
>
>
> http://Van.Tuyl.eu/
> http://members.chello.nl/hjgtuyl/tourdemonad.html
> Haskell programming
> --
>



-- 
Alberto.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/web-devel/attachments/20141105/3d26ab7e/attachment.html>

From kazu at iij.ad.jp  Fri Nov 21 02:08:00 2014
From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=))
Date: Fri, 21 Nov 2014 11:08:00 +0900 (JST)
Subject: [web-devel] http2
In-Reply-To: <20131218.145958.787674111820110914.kazu@iij.ad.jp>
References: <20131217.110330.2300511257227682677.kazu@iij.ad.jp>
 <CAHZrzdoYgQxjdbnWkDVVbs7UzPKVrzXeCVwooFDZ0Z+uYXGq0A@mail.gmail.com>
 <20131218.145958.787674111820110914.kazu@iij.ad.jp>
Message-ID: <20141121.110800.1820533358751026664.kazu@iij.ad.jp>

Hi web-devel,

This is an old topic talked one year ago. I have sticked on this
project since then and can report good news.

I have implemented ALPN to hs-tls, which is already
merged. Unfortunately, it was appeared that this is not good enough
for HTTP/2.  HTTP/2 requires TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 but
hs-tls does not support neither ECDHE nor AES GCM.  So, I have
implemented both which should be merged eventually.

A branch of Warp has integrated this hs-tls lib and http2 lib. This
warp app can communicate with Firefox Nightly and Chrome 39 (with
HTTP/2 enabled) by HTTP/2 over TLS now.

--Kazu

> Hi Greg,
> 
>> This is a nice start. I considered implementing SPDY myself soon after the
>> spec was first published but the TLS stuff seemed too daunting. At the time
>> I think Chrome was using a bunch of in-tree OpenSSL patches to support
>> next-protocol-negotiation / TLS snap start / etc. It looks like the HTTP 2
>> draft has gotten rid of those requirements but the TLS server name
>> indication extension must be supported. HsOpenSSL doesn't have bindings for
>> the needed functions (SSL_CTX_set_tlsext_servername_callback() /
>> SSL_get_servername()) and the tls library (which I am personally reluctant
>> to use for "crypto is hard to do right and you really want to use
>> widely-audited code" reasons) doesn't seem to have an implementation yet
>> either. OpenSSL support seems to be the easier nut to crack there.
> 
> Indeed, TLS is tough. All existing implementations of HTTP/2.0 are
> using OpenSSL HEAD, not released one. Also, spec is changing, i.e. NPN
> (SPDY's one, proposals from the server side) vs ALPN (current
> HTTP/2.0's one, proposals from the client side).
> 
> I finished inter-operability test of HPACK with one in nodejs and one
> in C. The next step is to implement HTTP/2.0 framing and plain-text
> communication. Then, I will tackle TLS stuff. If necessary, I will
> write bindings to OpenSSL.
> 
> --Kazu
> _______________________________________________
> web-devel mailing list
> web-devel at haskell.org
> http://www.haskell.org/mailman/listinfo/web-devel

From greg at gregorycollins.net  Fri Nov 21 02:22:26 2014
From: greg at gregorycollins.net (Gregory Collins)
Date: Thu, 20 Nov 2014 18:22:26 -0800
Subject: [web-devel] http2
In-Reply-To: <20141121.110800.1820533358751026664.kazu@iij.ad.jp>
References: <20131217.110330.2300511257227682677.kazu@iij.ad.jp>
 <CAHZrzdoYgQxjdbnWkDVVbs7UzPKVrzXeCVwooFDZ0Z+uYXGq0A@mail.gmail.com>
 <20131218.145958.787674111820110914.kazu@iij.ad.jp>
 <20141121.110800.1820533358751026664.kazu@iij.ad.jp>
Message-ID: <CAHZrzdo8Sfw_UZuwHuXdA3pbzfRCaxGbpOAgNCOr5_pEbSCbSg@mail.gmail.com>

Great work Kazu!!!

On Thu, Nov 20, 2014 at 6:08 PM, Kazu Yamamoto <kazu at iij.ad.jp> wrote:

> Hi web-devel,
>
> This is an old topic talked one year ago. I have sticked on this
> project since then and can report good news.
>
> I have implemented ALPN to hs-tls, which is already
> merged. Unfortunately, it was appeared that this is not good enough
> for HTTP/2.  HTTP/2 requires TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 but
> hs-tls does not support neither ECDHE nor AES GCM.  So, I have
> implemented both which should be merged eventually.
>
> A branch of Warp has integrated this hs-tls lib and http2 lib. This
> warp app can communicate with Firefox Nightly and Chrome 39 (with
> HTTP/2 enabled) by HTTP/2 over TLS now.
>
> --Kazu
>
> > Hi Greg,
> >
> >> This is a nice start. I considered implementing SPDY myself soon after
> the
> >> spec was first published but the TLS stuff seemed too daunting. At the
> time
> >> I think Chrome was using a bunch of in-tree OpenSSL patches to support
> >> next-protocol-negotiation / TLS snap start / etc. It looks like the
> HTTP 2
> >> draft has gotten rid of those requirements but the TLS server name
> >> indication extension must be supported. HsOpenSSL doesn't have bindings
> for
> >> the needed functions (SSL_CTX_set_tlsext_servername_callback() /
> >> SSL_get_servername()) and the tls library (which I am personally
> reluctant
> >> to use for "crypto is hard to do right and you really want to use
> >> widely-audited code" reasons) doesn't seem to have an implementation yet
> >> either. OpenSSL support seems to be the easier nut to crack there.
> >
> > Indeed, TLS is tough. All existing implementations of HTTP/2.0 are
> > using OpenSSL HEAD, not released one. Also, spec is changing, i.e. NPN
> > (SPDY's one, proposals from the server side) vs ALPN (current
> > HTTP/2.0's one, proposals from the client side).
> >
> > I finished inter-operability test of HPACK with one in nodejs and one
> > in C. The next step is to implement HTTP/2.0 framing and plain-text
> > communication. Then, I will tackle TLS stuff. If necessary, I will
> > write bindings to OpenSSL.
> >
> > --Kazu
> > _______________________________________________
> > web-devel mailing list
> > web-devel at haskell.org
> > http://www.haskell.org/mailman/listinfo/web-devel
> _______________________________________________
> web-devel mailing list
> web-devel at haskell.org
> http://www.haskell.org/mailman/listinfo/web-devel
>



-- 
Gregory Collins <greg at gregorycollins.net>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/web-devel/attachments/20141120/30008c1f/attachment.html>

From michael at snoyman.com  Fri Nov 21 05:03:53 2014
From: michael at snoyman.com (Michael Snoyman)
Date: Fri, 21 Nov 2014 05:03:53 +0000
Subject: [web-devel] http2
References: <20131217.110330.2300511257227682677.kazu@iij.ad.jp>
 <CAHZrzdoYgQxjdbnWkDVVbs7UzPKVrzXeCVwooFDZ0Z+uYXGq0A@mail.gmail.com>
 <20131218.145958.787674111820110914.kazu@iij.ad.jp>
 <20141121.110800.1820533358751026664.kazu@iij.ad.jp>
 <CAHZrzdo8Sfw_UZuwHuXdA3pbzfRCaxGbpOAgNCOr5_pEbSCbSg@mail.gmail.com>
Message-ID: <CAKA2JgKECZtK0NrYjg8E8DaMa2-sMuXE4RRTByp4kBXZ2vT4Bw@mail.gmail.com>

Seconded!

On Fri Nov 21 2014 at 4:22:31 AM Gregory Collins <greg at gregorycollins.net>
wrote:

> Great work Kazu!!!
>
> On Thu, Nov 20, 2014 at 6:08 PM, Kazu Yamamoto <kazu at iij.ad.jp> wrote:
>
>> Hi web-devel,
>>
>> This is an old topic talked one year ago. I have sticked on this
>> project since then and can report good news.
>>
>> I have implemented ALPN to hs-tls, which is already
>> merged. Unfortunately, it was appeared that this is not good enough
>> for HTTP/2.  HTTP/2 requires TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 but
>> hs-tls does not support neither ECDHE nor AES GCM.  So, I have
>> implemented both which should be merged eventually.
>>
>> A branch of Warp has integrated this hs-tls lib and http2 lib. This
>> warp app can communicate with Firefox Nightly and Chrome 39 (with
>> HTTP/2 enabled) by HTTP/2 over TLS now.
>>
>> --Kazu
>>
>> > Hi Greg,
>> >
>> >> This is a nice start. I considered implementing SPDY myself soon after
>> the
>> >> spec was first published but the TLS stuff seemed too daunting. At the
>> time
>> >> I think Chrome was using a bunch of in-tree OpenSSL patches to support
>> >> next-protocol-negotiation / TLS snap start / etc. It looks like the
>> HTTP 2
>> >> draft has gotten rid of those requirements but the TLS server name
>> >> indication extension must be supported. HsOpenSSL doesn't have
>> bindings for
>> >> the needed functions (SSL_CTX_set_tlsext_servername_callback() /
>> >> SSL_get_servername()) and the tls library (which I am personally
>> reluctant
>> >> to use for "crypto is hard to do right and you really want to use
>> >> widely-audited code" reasons) doesn't seem to have an implementation
>> yet
>> >> either. OpenSSL support seems to be the easier nut to crack there.
>> >
>> > Indeed, TLS is tough. All existing implementations of HTTP/2.0 are
>> > using OpenSSL HEAD, not released one. Also, spec is changing, i.e. NPN
>> > (SPDY's one, proposals from the server side) vs ALPN (current
>> > HTTP/2.0's one, proposals from the client side).
>> >
>> > I finished inter-operability test of HPACK with one in nodejs and one
>> > in C. The next step is to implement HTTP/2.0 framing and plain-text
>> > communication. Then, I will tackle TLS stuff. If necessary, I will
>> > write bindings to OpenSSL.
>> >
>> > --Kazu
>> > _______________________________________________
>> > web-devel mailing list
>> > web-devel at haskell.org
>> > http://www.haskell.org/mailman/listinfo/web-devel
>> _______________________________________________
>> web-devel mailing list
>> web-devel at haskell.org
>> http://www.haskell.org/mailman/listinfo/web-devel
>>
>
>
>
> --
> Gregory Collins <greg at gregorycollins.net>
>  _______________________________________________
> web-devel mailing list
> web-devel at haskell.org
> http://www.haskell.org/mailman/listinfo/web-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/web-devel/attachments/20141121/76139c42/attachment.html>

From kolmodin at gmail.com  Fri Nov 21 07:24:27 2014
From: kolmodin at gmail.com (Lennart Kolmodin)
Date: Fri, 21 Nov 2014 07:24:27 +0000
Subject: [web-devel] http2
References: <20131217.110330.2300511257227682677.kazu@iij.ad.jp>
 <CAHZrzdoYgQxjdbnWkDVVbs7UzPKVrzXeCVwooFDZ0Z+uYXGq0A@mail.gmail.com>
 <20131218.145958.787674111820110914.kazu@iij.ad.jp>
 <20141121.110800.1820533358751026664.kazu@iij.ad.jp>
 <CAHZrzdo8Sfw_UZuwHuXdA3pbzfRCaxGbpOAgNCOr5_pEbSCbSg@mail.gmail.com>
 <CAKA2JgKECZtK0NrYjg8E8DaMa2-sMuXE4RRTByp4kBXZ2vT4Bw@mail.gmail.com>
Message-ID: <CAHQ09u3+4RyHadhm+9+Fsk9f7fCFQ5MDN23b5W0e7kvsEbJFHQ@mail.gmail.com>

Great work, well done!

On Fri, 21 Nov 2014 08:03 Michael Snoyman <michael at snoyman.com> wrote:

> Seconded!
>
> On Fri Nov 21 2014 at 4:22:31 AM Gregory Collins <greg at gregorycollins.net>
> wrote:
>
>> Great work Kazu!!!
>>
>> On Thu, Nov 20, 2014 at 6:08 PM, Kazu Yamamoto <kazu at iij.ad.jp> wrote:
>>
>>> Hi web-devel,
>>>
>>> This is an old topic talked one year ago. I have sticked on this
>>> project since then and can report good news.
>>>
>>> I have implemented ALPN to hs-tls, which is already
>>> merged. Unfortunately, it was appeared that this is not good enough
>>> for HTTP/2.  HTTP/2 requires TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 but
>>> hs-tls does not support neither ECDHE nor AES GCM.  So, I have
>>> implemented both which should be merged eventually.
>>>
>>> A branch of Warp has integrated this hs-tls lib and http2 lib. This
>>> warp app can communicate with Firefox Nightly and Chrome 39 (with
>>> HTTP/2 enabled) by HTTP/2 over TLS now.
>>>
>>> --Kazu
>>>
>>> > Hi Greg,
>>> >
>>> >> This is a nice start. I considered implementing SPDY myself soon
>>> after the
>>> >> spec was first published but the TLS stuff seemed too daunting. At
>>> the time
>>> >> I think Chrome was using a bunch of in-tree OpenSSL patches to support
>>> >> next-protocol-negotiation / TLS snap start / etc. It looks like the
>>> HTTP 2
>>> >> draft has gotten rid of those requirements but the TLS server name
>>> >> indication extension must be supported. HsOpenSSL doesn't have
>>> bindings for
>>> >> the needed functions (SSL_CTX_set_tlsext_servername_callback() /
>>> >> SSL_get_servername()) and the tls library (which I am personally
>>> reluctant
>>> >> to use for "crypto is hard to do right and you really want to use
>>> >> widely-audited code" reasons) doesn't seem to have an implementation
>>> yet
>>> >> either. OpenSSL support seems to be the easier nut to crack there.
>>> >
>>> > Indeed, TLS is tough. All existing implementations of HTTP/2.0 are
>>> > using OpenSSL HEAD, not released one. Also, spec is changing, i.e. NPN
>>> > (SPDY's one, proposals from the server side) vs ALPN (current
>>> > HTTP/2.0's one, proposals from the client side).
>>> >
>>> > I finished inter-operability test of HPACK with one in nodejs and one
>>> > in C. The next step is to implement HTTP/2.0 framing and plain-text
>>> > communication. Then, I will tackle TLS stuff. If necessary, I will
>>> > write bindings to OpenSSL.
>>> >
>>> > --Kazu
>>> > _______________________________________________
>>> > web-devel mailing list
>>> > web-devel at haskell.org
>>> > http://www.haskell.org/mailman/listinfo/web-devel
>>> _______________________________________________
>>> web-devel mailing list
>>> web-devel at haskell.org
>>> http://www.haskell.org/mailman/listinfo/web-devel
>>>
>>
>>
>>
>> --
>> Gregory Collins <greg at gregorycollins.net>
>>  _______________________________________________
>> web-devel mailing list
>> web-devel at haskell.org
>> http://www.haskell.org/mailman/listinfo/web-devel
>>
> _______________________________________________
> web-devel mailing list
> web-devel at haskell.org
> http://www.haskell.org/mailman/listinfo/web-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/web-devel/attachments/20141121/2cd9425e/attachment-0001.html>