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