It's not the concept of timeout I object, but specifying the values
for them. If you assume the implementation handles all the little
details, then they can set a treasonable imeout value too (and tuning
that is like all other transport parameters, not covered by this api).
We still have two possible outcomes: a response or timeout.

On Sat, Mar 14, 2020 at 9:51 AM John Cowan <xxxxxx@ccil.org> wrote:
>
> I think we do, because as a user I can just close the tab/window, but a program needs to be able to recover from being hung up.
>
> On Fri, Mar 13, 2020 at 10:15 PM Duy Nguyen <xxxxxx@gmail.com> wrote:
>>
>> 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

--
Duy