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
