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