guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] read-response-body should return received data when error oc


From: Nala Ginrut
Subject: Re: [PATCH] read-response-body should return received data when error occcurs (V2)
Date: Fri, 16 Mar 2012 16:47:38 +0800

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 Fri, Mar 16, 2012 at 3:32 PM, Daniel Hartwig <address@hidden> wrote:
On 16 March 2012 13:54, Nala Ginrut <address@hidden> 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 return
> 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 return
> it, and let the user  determine whether it's an error or continue reading.

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]


reply via email to

[Prev in Thread] Current Thread [Next in Thread]