21:42:25 <donri> crazy thought: could we do type safe http headers for happstack 8 / hyperdrive? reading [1] and it mentions that many sites send invalid headers
21:42:30 <donri> [1] http://www.veracode.com/blog/2012/11/security-headers-report/
21:43:19 <stepkut> what would that involve/mean?
21:44:27 <donri> data Header = Host Text | ... | X Text Text | UnsafeHeader Text Text
21:45:51 <donri> preferably with type-safe header values as well, where possible
21:49:24 <stepkut> i think at the hyperdrive level we would want to use something more primitive, but we could add something fancier on top of that in a higher level lib?
21:49:30 <donri> yea
21:49:48 <donri> also mainly talking about responses here, although something could maybe be done for request headers too
21:50:29 <donri> like, if you have an ADT for those you avoid typo errors in getHeaderM etc
21:56:36 <donri> possibly with values for known headers parsed as well
22:00:02 <donri> I wonder if we could use boomerang for bidirectional parsing-printing of headers... although not sure that's useful unless we share code with a http client lib?
22:00:13 <donri> are any headers shared between request and response
22:06:16 <stepkut> boomerang doesn't seem like the best match
22:06:33 <stepkut> in part because there are a lot of alternative, but valid representations for headers when you include whitespace
22:07:41 <stepkut> also, boomerang is about ensuring internal consistency, but that doesn't ensure it is actually conforming to any external spec
22:07:54 <stepkut> for HTTP, we have an external defined EBNF spec
22:07:58 <donri> true
22:08:07 <stepkut> so, we want to make sure that our parsers and printers are obey that spec
22:08:09 <stepkut> obeying
22:08:18 <stepkut> so, I have the ebnf parser written already
22:08:34 <stepkut> the next step is figuring out how to tie that into the parser
22:08:54 <stepkut> I am going to update hyperdrive to pipes 2.5 + ResourceT
22:09:01 <stepkut> and then we can look at the parser issue
22:10:25 <donri> are you gonna try the pipes parser?
22:12:20 <stepkut> perhaps
22:13:27 <stepkut> the problem of making a parser than can be proven to conform to an EBNF spec is tricky enough with additional constraints
22:13:42 <stepkut> we can already handle leftovers, which was the big problem before
22:14:06 <stepkut> maybe once the technique is understood, it will be possible to apply it to the pipes parser
22:14:13 <donri> aha