Well, I saw your point. So read-response-body is defined to read the whole
body, and shouldn't return anything when it didn't get all the data.
For this reason, one should use bytevector handler to get the data on one's
own rather than read-response-body.
Well, I just thought read-response-body is the only API to get body, at
least from the manual, I can only get this conclusion. But in fact, the
worth of read-response-body is very limited. It just a simple procedure to
get a simple page or few data.
If possible, I wish the manual can add few words to notice this.
> On 16 March 2012 13:54, Nala Ginrut <nalaginrut@gmai...> wrote:
> > This patch will return any data get-bytevector-n received and throw error
> > when get <eof>.
> > Actually, it's not the same feature in the old version thread
> > http://lists.gnu.org/archive/html/guile-devel/2012-03/msg00116.html > > The old version is complicated because it catches *any* exception and
> > the received data within exception.
> > But this new version is an easy one.
> Yes, it looks much nicer :-)
> > My point is, read-response-body is a low level procedure, so we shouldn't
> > make it complex. But our current doesn't return received data when
> > the received data is less than the content-length. I think it should
> > it, and let the user determine whether it's an error or continue
> So r-r-b is a really a two-liner:
> - read response body from port;
> - make sure the complete response has been read.
> This combination is the utility of the procedure: it guarentees that
> the data it returns comprises the complete response body.
> With your proposed change, that guarentee no longer holds. The caller
> now must perform their own checks on the response data size, making
> your function effectively this:
> - read response body data from port.
> So what is the utility of calling a procedure to do that over, say,
> reading from the port directly? [pointed out earlier in this thread]