On Sun, 30 Nov 2008, Henning Thielemann wrote:
On Sat, 29 Nov 2008, Henning Thielemann wrote:
On Sat, 29 Nov 2008, Henning Thielemann wrote:
On Thu, 27 Nov 2008, Henning Thielemann wrote:
I have HTTP-3001.0.4 and I like to check the HTTP response headers before downloading the entire document.
I have tried to solve this on my own. I have written a wrapper to any stream type. It first reads the entire document lazily into a string and then ships its contents when readBlock or readLine is called. However, the program blocks on 'close' now and I don't know why. (See LazyStream.example)
Is anyone else interested in getting HTTP response bodies lazily in general and trying my code in particular? Maybe some of the experts have an idea, why 'close' blocks.
I have got an idea by myself. On the one hand 'close' checks with a pattern match whether the buffer is empty, on the other hand 'close' checks whether the connection is active or closed. Both of these check will certainly force the lazy read to be completed.
I'll continue my thread ... I think it is best to build the lazy stream on top of Network.Socket, not Network.TCP, since the first one does not buffer and the second one does. Since my lazy stream reads the entire source content into a single String lazily, I already have a buffer. In order to not duplicate code, I'd like to introduce a hidden module Network.TCP.Private with open and close methods, which can then be used by Network.TCP and Network.Stream.Lazy. Alternatively I could add a new public module for unbuffered TCP transfer. I think this would be even cleaner. However, I had to name the new module, say, Network.TCP.Unbuffered and the module names Network.TCP.Unbuffered+Network.TCP are somehow the wrong way round compared to Network.TCP+Network.TCP.Buffered. Maybe I should name them Network.TCP.Unbuffered+Network.TCP.Buffered and re-export the latter one in Network.TCP. Have such changes a chance to get included into HTTP package?