
On Jun 14, 2008, at 7:16 PM, Felipe Lessa wrote:
On Sat, Jun 14, 2008 at 1:50 PM, Sebastiaan Visser
wrote: Doesn't this imply that the parseHttpHeader must work on ByteStrings instead of regular Strings?
I made the change because it's easier and faster to go from ByteString to String than the converse.
Maybe this works for HTTP headers, but sometimes ByteStrings are not appropriate. Especially when you are not using the regular `System.IO.hGetContents' but the `System.IO.UTF8.hGetContents'.
You may use the package encoding instead, take a look at [1]. It will decode a lazy ByteString into a String. In your HTTP parsing example, you could break the ByteString on "\r\n\r\n" and then decodeLazy only the first part, while returning the second without modifying it.
Sounds interesting. This could indeed solve (a part of) my problem. The thing is, when decoding the header - in my web server architecture - it is not yet clear what should be done be the body. Some `handlers' may want to have it as a String, UTF8 String, ByteString or may not even need it at all.
[1] http://hackage.haskell.org/packages/archive/encoding/0.4.1/doc/ html/Data-Encoding.html#v%3AdecodeLazy
Because HTTP headers are line based and the parser does not need any look ahead - the first "\r\n\r\n" is the header delimiter - it might be possible to use the hGetLine for the headers. After this I am still `free' to decide what to do for the body: System.IO.hGetContents, System.IO.UTF8.hGetContents, Data.ByteString.Lazy.hGetContents, hClose, etc...
-- Felipe.
Thanks, Sebastiaan.