You're making me think that SRFI 177 is important for more than just existing, growing APIs.
In a sense this API is pre-grown. HTTP/0.9 was dirt simple: gimme a verb, gimme an URL, get back a sequence of bytes: less complex than Gopher. But HTTP/1.1 has an overwhelming number of features. Trying to refine them to just these few is hard.
Sometimes, the Smalltalk approach of naming every argument at every call site seems smart.
In Harlan, my favorite toy language (only in my head so far), all calls are keyword calls, with two exceptions: if a call has exactly two arguments named left and right, it can be called as a (lowest-priority) binary operator, and if it has exactly one argument, it can be called as a unary operator. Unlike Smalltalk, they can be in any order desired; unlike Python, there are no BOA arguments at all.
Reflecting further on retrieving response-bodies, I guess what needs to be done is to have the request object point to a thunk that returns the next n bytes into a bytevector buffer. This would require another item in the request object, the buffer, whose size specifies n. Convenience procedures that call SRFI 158 generator-fold can convert the chunks into a single bytevector or string.
If the implementation also has custom ports, they can be used to expose this thunk as an input port. (Using the underlying socket port doesn't work because HTTP persistent connections.)