[web-devel] Lazy simpleHTTP
Henning Thielemann
lemming at henning-thielemann.de
Sun Dec 14 16:23:58 EST 2008
On Tue, 2 Dec 2008, Paul Brown wrote:
> I'm still a little lost as to why this is necessary and/or desirable. Some
> (if not all) of your use cases would be achievable via proper use of HTTP
> protocol features (100 Continue, Conditional GET, etc.), and it is a question
> of whether those are well supported by the current implementation.
I do not know, how '100 Continue' would help, since this is for
conditionally sending the body of the HTTP request, not conditionally
receiving the body of the HTTP response, right? However, you are right, in
principle it would help me to use HTTP features, like the Accept header.
Using it, I could tell, that I only want certain types of data to be send.
However, e.g. the original HWS ignores the Accept header and when I
checked other web servers, they do so, as well. So it still seems to be
the best, to get the header via a GET request and cancel the transfer,
once I have seen enough of the header.
> For the laziness in handling response bodies, I think you'd actually
> want to expose an iteration semantic implemented on top of HTTP chunked
> encoding and ranged requests, and that would live at a higher level in
> the stack than the TCP layer.
Yes, I also want lazy download of the body. Certainly an iteratee
implementation could be cleaner, but probably considerably different from
the current implementation. I'm afraid 'Range' is supported as bad as
'Accept' - and what about dynamically generated (maybe even infinite)
content? So I think I should not bother the web server with the way I want
to download its content, but just mimic a stupid browser.
My current state can be found here:
http://code.haskell.org/~thielema/http/
I do not want to fork and I hope the patches are accepted somewhen and
nobody adds conflicting patches in the meantime, since this would mean I
have to re-record all my changes in order to avoid the dreaded exponential
time darcs conflict resolution. However, currently there are only changes
behind the scenes and no new visible features. I'm now using monad
transformers from my explicit-exception package, which simplified a lot of
the manual exception handling before. I removed some 'reverse's, which are
a laziness killer, but I'm still not at the end. Chunked transfer is
particularly difficult with respect to laziness, although I do not know
why.
I have added a Monad which further abstracts the Stream concept. It
allows us to do HTTP communication in absence of IO, which is perfect for
unit testing and allows lazy processing without unsafeInterleaveIO - you
only need the unsafeInterleaveIO hidden in hGetContents.
More information about the web-devel
mailing list