Fixing trac bug number 188

svn: r15092
This commit is contained in:
Jay McCarthy 2009-06-05 14:54:20 +00:00
parent bbc24b5e68
commit 3b2557805d
2 changed files with 15 additions and 10 deletions

View File

@ -110,10 +110,13 @@
(begin
((response/incremental-generator bresp)
(lambda chunks
(fprintf o-port "~x\r\n"
(apply + 0 (map bytes-length chunks)))
(for-each (lambda (chunk) (display chunk o-port)) chunks)
(fprintf o-port "\r\n")))
(define length (apply + 0 (map bytes-length chunks)))
(if (zero? length)
(flush-output o-port)
(begin
(fprintf o-port "~x\r\n" length)
(for-each (lambda (chunk) (display chunk o-port)) chunks)
(fprintf o-port "\r\n")))))
; one \r\n ends the last (empty) chunk and the second \r\n ends the (non-existant) trailers
(fprintf o-port "0\r\n\r\n")))]))

View File

@ -199,7 +199,9 @@ Here is an example typical of what you will find in many applications:
([generator ((() () #:rest (listof bytes?) . ->* . any) . -> . any)])]{
As with @scheme[response/basic], except with @scheme[generator] as a function that is
called to generate the response body, by being given an @scheme[output-response] function
that outputs the content it is called with.
that outputs the content it is called with. If the @scheme[output-response] function is called
with arguments of zero length (when concatenated), then the output port is flushed with
@scheme[flush-output].
Here is a short example:
@schemeblock[
@ -208,11 +210,11 @@ Here is an example typical of what you will find in many applications:
#"application/octet-stream"
(list (make-header #"Content-Disposition"
#"attachment; filename=\"file\""))
(lambda (send/bytes)
(send/bytes #"Some content")
(send/bytes)
(send/bytes #"Even" #"more" #"content!")
(send/bytes #"Now we're done")))
(lambda (output-response)
(output-response #"Some content")
(output-response)
(output-response #"Even" #"more" #"content!")
(output-response #"Now we're done")))
]
}