Hello,

I've written a small client that sends http requests to a server and also receives the answers and does some processing on them. I use boost::asio to create tcp sockets and manually create the headers to request certain resources. This works fine on my laptop which has Comodo Firewall installed. At work, we have to use Norton (and some of our clients too) which seems to trigger some unusual behaviour. Every now and then, after sending an http request, my read handler is called with an eof error. This only happens when the Norton Firewall is enabled: Once I disable it, my application displays the same behaviour as it does at home.

After my socket is connected, I use boost::asio::async_write to send the request. Once my write_handler is called, I issue a boost::asio::async_read_until with "\r\n" as the delimiter so I can parse the answer of the server. However every now and then (about 1/4th of the time) the read_handler is called with an eof error.

In my tests, I always used the same server and these problems only showed up when said Firewall was active. I am unsure why my Application triggers that behaviour - maybe I'm doing something wrong?

Can you give me any advice how to trace down that bug?

In my tests, I always used the same server and these problems only showed up when said Firewall was active. I am unsure why my Application triggers that behaviour - maybe I'm doing something wrong?

1) Uninstall Norton
2) Be happy :-)

It's quite possible that Norton inserts itself into the request chain, and does something that's not 100% kosher. For example, it may close a socket before all the data has been sent, assuming that the application will be able to buffer the data.

First, I would re-write the important part of the logic on top of simple connect(), send() and recv(), to see if it works. If you still get the error, you have to talk to Norton tech support (and they'll laugh and laugh all the way to the bank, but at least you made an effort).
Second, if that doesn't reproduce the problem, you have to debug this into the boost library, the hard way. It may be some boost bug, who knows?

Or just detect that you get an error before you have a complete response, re-try the request. It's a sucky thing to have to do, but users prefer working software to correct software :-)

Thank you very much for your response.
The first time I got that bug, I had quite a similar thought, however for some reason my superiors won't be happy with that solution ;-)

I'll have to write a simple application that uses boost::asio and one that uses the (bsd?) socket api. Let's hope I can reproduce the behaviour.
Anyways I will report back once I have results.