[web-devel] Re: Lazy simpleHTTP

[Henning Thielemann]

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?