为什么我不能在打印hGetContents的结果后使用hPutStr？

Question

I'm new to stackoverflow so forgive me if I do something wrong. I trying to understand how a simple server would work in Haskell. I think I'm missing something very simple or fundamental about how hGetContents works.

import Network 
import System.IO

main = withSocketsDo $ do
     socket <- listenOn $ PortNumber 5002
     (h, _, _) <- accept socket
     c <- hGetContents h
--   putStrLn c  -- doesn't work
--   putStrLn $ head $ lines c -- works!
--   putStrLn $ unlines $ take 2 $ lines c -- works!
--   putStrLn $ unlines $ take 3 $ lines c -- works!
--   putStrLn $ unlines $ take 6 $ lines c -- works!
     putStrLn $ unlines $ take 10 $ lines c -- doesn't work
     hPutStr h $ "HTTP/1.0 200 OK\r\nContent-Length: 5\r\n\r\nHello!\r\n"
     hClose h

After running the program, I navigate via web browser to http://localhost:5002 . The problem seems to be that, depending on how much I've parsed the handle contents, I eventually am unable to send a response. I'd like to be able to parse the request before I send a response. I've commented in the code the cases that work and the cases that don't. Hoogle says that for hGetContents (lazy) the handle is "semi-closed" as it is being read. Am I misunderstanding the laziness or should I consider the handle closed once I begin parsing its contents?

The error I get is "hPutChar: resource vanished (Broken pipe)." Thanks for any help.

Answer 1

I tried to reproduce your problem. For that I executed your code and send it a request using nc:

printf "1\n2\n3\n4\n5\n6\n7\n8\n9\n10\n11" | nc localhost 5002

As expected the server (code from your question) printed out first 10 lines and exited without any error. The client (nc) printed:

HTTP/1.0 200 OK
Content-Length: 5
Hello!

and also exited without an error.

So, at first I couldn't understand what's your problem, but then I tried to send a smaller request:

printf "1\n2\n3\n4\n5\n6\n" | nc localhost 5002

The server printed first 6 lines and didn't exit. The client also didn't exit, so I interrupted it with Ctrl-C and after that the server exited with "resource vanished" error.

I took some thinking and it started making sense to me. I don't understand lazy IO too good, so if my explanation isn't clear or correct it would be helpful if someone with better understanding would improve it.

Let's follow your code. First:

(h, _, _) <- accept socket
c <- hGetContents h

You open a handle and read it's content. Note that the handle is lazy and the content that you get is also lazy. When we say that something is lazy we mean that it can be passed around without being evaluated (it's often referred as 'call by name' vs 'call by value').

Now:

putStrLn $ unlines $ take 10 $ lines c

Here it is, you pass your lazy, unevaluated content to another function take 10 . take 10 will try to evaluate first 10 elements of a list and return them, if there are less than 10 elements in the list it would simply return all of them. After take 10 we have putStrLn and unlines which both perfectly compatible with laziness.

Now let's say that client sends an input that is only 6 lines long and then starts waiting for the respond. Our server lazily receives the content and tries to print first 10 lines. First, take 10 function happily consumes the first 6 lines and passes them over to putStrLn . unlines putStrLn . unlines , what happens then? take 10 can't just finish it's output because there is absolutely no indication that it is the end. The handle is still open, bytes still can be floating from client to server, so it just waits for more input.

This behaviour can be observed by running:

nc localhost 5002

and manually typing there 10 lines. The input would appear on server line-by-line as you type. After you will type the 10th line the server will respond with "Hello" message.

PS: I guess that the behaviour that you described happens because you web browser sends 6 to 9 lines of something with the request.

To test, debug and analyze this kind of low level servers you should use simple tools like nc and curl instead of your web browser :)

Answer 2

When you initiate a lazy read on a handle, you give up the right to do anything much else with the handle until the contents string is fully forced, or you close the handle manually (at which point attempting to force any more of the contents string will lead to bad behavior or an error).

TL;DR

This is not a situation where lazy I/O is appropriate. The situations where a lazy read on a socket is appropriate can probably be counted on zero fingers. You can use regular strict I/O if you like, or conduit , or pipes , or some Haskell web framework like Yesod or Scotty or various other competitors.

Answer 3

Calling hGetContents puts the handle into a "semi-closed" state. You should not perform any operations on the handle after that point. You should only use the string returned from hGetContents .

Put simply, don't use lazy I/O here. You need to manually read and write individual strings one at a time, since the timing matters.

In general, lazy I/O is kind of neat, but it doesn't work well for anything much beyond toy examples.