Re: read-response-body of (web response) depends on Content-Length but ...

[Sunjoong Lee]

The urgent patch posted before makes a bug, so I cancel it and repost:

########## cut here ##########

--- /usr/share/guile/2.0/web/response.scm 2012-04-22 04:36:06.753878689 +0900

+++ response.scm 2012-04-27 19:54:55.539304271 +0900

@@ -217,13 +217,16 @@

 (define (read-response-body r)

   "Reads the response body from @var{r}, as a bytevector.  Returns

address@hidden if there was no response body."

+  (let ((te (response-transfer-encoding r)))

+    (if (and te (eq? 'chunked (car (car te))))

+        (get-bytevector-all (response-port r))

   (let ((nbytes (response-content-length r)))

     (and nbytes

          (let ((bv (get-bytevector-n (response-port r) nbytes)))

            (if (= (bytevector-length bv) nbytes)

                bv

                (bad-response "EOF while reading response body: ~a bytes of ~a"

-                            (bytevector-length bv) nbytes))))))

+                            (bytevector-length bv) nbytes))))))))

 

 (define (write-response-body r bv)

   "Write @var{body}, a bytevector, to the port corresponding to the HTTP

@@ -269,6 +272,7 @@

 (define-response-accessor content-type #f)

 (define-response-accessor expires #f)

 (define-response-accessor last-modified #f)

+(define-response-accessor transfer-encoding #f)

 

 ;; Response headers

 ;;

########## cut here ##########

2012/4/27 Sunjoong Lee <address@hidden>

+(define-response-accessor transfer-encoding '()) 

2012/4/27 Sunjoong Lee <address@hidden>

I googled and found http://tools.ietf.org/html/rfc2616 .

In a section of "4.4 Message Length":

  2.If a Transfer-Encoding header field (section 14.41) is present and

     has any value other than "identity", then the transfer-length is

     defined by use of the "chunked" transfer-coding (section 3.6),

     unless the message is terminated by closing the connection.

  3.If a Content-Length header field (section 14.13) is present, its

     decimal value in OCTETs represents both the entity-length and the

     transfer-length. The Content-Length header field MUST NOT be sent

     if these two lengths are different (i.e., if a Transfer-Encoding

     header field is present). If a message is received with both a

     Transfer-Encoding header field and a Content-Length header field,

     the latter MUST be ignored.