On Mon, Apr 14, 2008 at 4:54 AM, Daniel Yokomizo <[EMAIL PROTECTED]> wrote: > Both request and response accept any entity headers and 7.1 (of RFC > 2616) says that a valid entity header is an extension header, which > can be any kind of header.
Is wasn't suggesting that other headers be dropped, just that they remain as strings. > IMHO it would be better to create a two layered approach. The bottom > layer handles the request as a bunch of strings, just checks for > structural correctness (i.e. break the headers by line and such) > without checking if the headers are correct. The top layer provides a > bunch of parser combinators to validate, parse and sanitize the > request so a library can create its own contract: Ok, I think I'm convinced by this argument. I'd hope that a standard set of header parsers be defined, and that an application which only cares about 2616 headers can do call a single function to parse them all, but I no longer advocate that the base interface use parsed forms of headers. Also, parsing URLs seems to be pretty uncontroversial (maybe parsing key, value pairs from the path, maybe not) AGL -- Adam Langley [EMAIL PROTECTED] http://www.imperialviolet.org _______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
