Thanks for the feedback!
However, it might be better to use a record type for the request and response, putting the mandatory information, e.g. the request URL, HTTP version, and verb, in the record's slots, and putting everything else in a dictionary slot.
This seems very arbitrary to me. In particular, content is mandatory with PUT, POST, PATCH (unless file is provided) and forbidden/useless with other verbs. So there's a lot of interdependencies.
Yes, there are definitely many interdependencies. I've always wondered whether that was a sign of poor protocol design, but I've never convinced myself one way or the other.
Still, type, URL, verb, HTTP version, headers, and timeout are included with every request. It seems cleaner to privilege them for that reason.
Also, almost everything you mentioned that isn't mandatory is in the headers, so perhaps just keep a dictionary of headers and provide procedures for extracting information like content type,
I agree that content-type and content-encoding can be eliminated.
I think that having a cookie jar data structure is the Right Thing, since you can just keep it in a variable, pass it in the request, and reassign the variable from the response.
Yes, that makes sense. I had some doubts about that one when I sent my message.
They really belong with an URL SRFI yet to be written.
Yes. In my request structure, I keep both the pure string and a parsed representation. Both are frequently useful, and it's nice not to have to convert between them unnecessarily — more than once, that is.