By that argument, we don't need connection-timeout and read-timeout either.

On Sat, Mar 14, 2020 at 9:10 AM John Cowan <xxxxxx@ccil.org> wrote:
>
> I don't see why I'd worry about that any more than I worry about it when I'm using a browser.  This isn't an all-singing, all-dancing client; it's what I think you need to write Scheme programs that can access HTTP resources.
>
> On Fri, Mar 13, 2020 at 10:05 PM Duy Nguyen <xxxxxx@gmail.com> wrote:
>>
>> You may want to shut down the connections at some point. If everything
>> is hidden away, will these connections persist until the end of the
>> program, or terminate after some idle time (and if so, how do we
>> specify it)? How many connections can persist at the same time?
>>
>> On Sat, Mar 14, 2020 at 8:58 AM John Cowan <xxxxxx@ccil.org> wrote:
>> >
>> > I figure persistent connections and HTTP/2 can be handled internally to the implementation.   The client program should not have to care one way or the other, as the high-level semantics are completely unchanged by these transport-level improvements.
>> >
>> > On Fri, Mar 13, 2020 at 9:50 PM Duy Nguyen <xxxxxx@gmail.com> wrote:
>> >>
>> >> On Fri, Mar 13, 2020 at 3:06 AM John Cowan <xxxxxx@ccil.org> wrote:
>> >> >
>> >> > This is meant for simple HTTP(S) requests.
>> >>
>> >> Just to be sure, this covers HTTP/1.1, not HTTP/2, or both?
>> >>
>> >> >  The idea is that there is a procedure, http-request, that accepts a request dictionary and returns a reply dictionary.  In this context, dictionary is some unspecified key-value data structure.  Most of the dictionaries have symbol keys.
>> >> >
>> >> > Redirects are performed automatically until a loop is seen or too many redirects: responses are chained using the request field of the response dictionary
>> >> >
>> >> > Compression is automatically undone on received content, and must be specified on sent content
>> >> >
>> >> > Request dictionary:
>> >> >
>> >> > type: 'request
>> >> > url: a string with the URL to request
>> >> > verb: a symbol (upper cased on the wire) representing the HTTP verb
>> >> > params: a dictionary mapping parameter names to parameter value strings (overrides the query part of the URL)
>> >> > headers: dictionary of random request headers
>> >> > content-type: media type of the content (string)
>> >> > content-encoding: how the outgoing content is compressed (symbol)
>> >> > cookies: a cookie jar (see below)
>> >> > connection-timeout: time in jiffies for TCP connection
>> >> > read-timeout: time in jiffies to send and receive the whole response
>> >> > content: a string (encoded in UTF-8) or bytevector to send, or an input port to read chars or bytes from (possibly streaming)
>> >> > file: a local file to send (mutually exclusive with content)
>> >> > response-style: indicates how response content is delivered (string, bytevector, possibly binary or textual input port if provided by the implementation)
>> >>
>> >> How do we handle connection reuse? I suppose we can just have a
>> >> mutable "session" item in this dictionary?
>> >> --
>> >> Duy
>>
>>
>>
>> --
>> Duy



--
Duy