Re: Working http-get example and still unsolved problem

[Ian Price]

Sunjoong Lee <address@hidden> writes:

> Hi, Ian;
>
> 2012/5/7 Ian Price <address@hidden>
>
>     Thanks for pointing this out, and if you have other comments on the
>     implementation (and the close-port issue), I'll be happy to have them.
>
> I don't understand the "close-port issue" exactly so this might be nonsense. 
> I think you mean comment-out-ed (close-port port) of close in 
> make-chunked-input-port.
Well, I mentioned it in the thread where I posted the patch, but to
briefly summarise

(define a <port>)
(define b (make-chunked-input-port a))
(close-port b)

What is the state of a?

(define c <port>)
(define d (make-chunked-output-port c))
(close-port d)

Likewise for c.

If you take, say, Java's BufferedReader, when the BufferedReader is
closed, it also closes the underlying Reader. This behaviour is
convenient, as you layer ports on top of one another, you only need to
worry about closing the top-most one. Since chunked transfer encoding is
only one of the possible encodings for http requests (though the only
one required by HTTP 1.1), it is possible that we would eventually want
to layer, say, gzip on top of chunked transfer encoding ports.

The issue with having this behaviour, is that while propagating the
close may be necessary to ensure proper behaviour, we don't necessarily
want to close the original socket. In particular, we might want to reuse
the same socket for multiple requests to the same http server.

> http-get in client.scm calls close-port when keep-alive? keyword be false 
> value. http-post of Greg Benison's use keep-alive? keyword only when making 
> headers and does not
> call close-port; this is why my cc-ing to Greg.

This is exactly the sort of issue I'm referring to.

>
> In this today morning, I had thought what points need to patch if being https 
> support. I had no experience to making that kind of codes and can't imagine I 
> myself write it, so
> just a thought.
>
> open-socket-for-uri need to make a session using gnu-tls; it does handshake 
> with a server and so on. http-get (and http-post) need to send bye to that 
> session when keep-alive?
> keyword be false value. So, close-port might be a role of http-get?
>
a #:keep-alive? type keyword is the solution I'm suggesting, as it would
allow a hypothetical

(close-port
  (make-deflate-input-port
    (make-chunked-input-port socket #:close-underlying-port? #f)))

to perform the necessary cleanup for the transfer encoding ports, while
still keeping the original socket open for reuse. http-get doesn't need
to factor into this design decision at all, though the use of
#keep-alive? there does suggest that a solution like this may be
necessary.

Anyway, just talking about it out loud, seems to have convinced my that
this is "the right thing", though I'm not sure of the keyword
name. #:keep-alive? could work in a pinch, I guess.

Yours overthinkingly,

-- 
Ian Price

"Programming is like pinball. The reward for doing it well is
the opportunity to do it again" - from "The Wizardy Compiled"