From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Josep Portella Florit Newsgroups: gmane.lisp.guile.devel Subject: Comments on the web modules Date: Sun, 01 Jun 2014 13:18:04 +0200 Message-ID: <87lhtgc1zn.fsf@primfilat.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1401621521 24654 80.91.229.3 (1 Jun 2014 11:18:41 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 1 Jun 2014 11:18:41 +0000 (UTC) To: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sun Jun 01 13:18:34 2014 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Wr3mb-0003bj-CV for guile-devel@m.gmane.org; Sun, 01 Jun 2014 13:18:33 +0200 Original-Received: from localhost ([::1]:40421 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wr3ma-0003W5-WC for guile-devel@m.gmane.org; Sun, 01 Jun 2014 07:18:33 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45568) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wr3mP-0003Vp-CL for guile-devel@gnu.org; Sun, 01 Jun 2014 07:18:28 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Wr3mH-0002YN-SF for guile-devel@gnu.org; Sun, 01 Jun 2014 07:18:21 -0400 Original-Received: from primfilat.com ([71.19.154.166]:59749) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wr3mH-0002YD-Mm for guile-devel@gnu.org; Sun, 01 Jun 2014 07:18:13 -0400 Original-Received: from x60 (unknown [46.18.46.105]) by primfilat.com (Postfix) with ESMTPSA id 951DC7B99D for ; Sun, 1 Jun 2014 13:18:10 +0200 (CEST) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] X-Received-From: 71.19.154.166 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:17178 Archived-At: Hi! I have some comments on the web modules: 1) The web server handlers receive a request object and the body as a bytevector. I think it would be more flexible to pass the request object only, and let the handler decide how to read the body from the port of the request object; it would allow processing large bodies without being bound by RAM. 2) The web server handlers must return a response object (or an alist of headers) and a body, which may be a bytevector, a string or a procedure that accepts a port argument. In the case of the procedure, the output to the port is accumulated into a bytevector, and then written to the client's port. I think it should be written to the client's port directly; it would allow to write large bodies without being bound by RAM. This would imply that, if the content-length is not set, the port should be wrapped by a chunk-encoded port (I know you have already thought about this, according to the `sanitize-response' documentation), or else the connection should be closed after the procedure returns. 3) The web server should add the client's sock-addr to the meta alist of the request object. I know you planned to do this, according to the `request-meta' documentation and the (web server http) source. Instead of taking the `cdr' of `accept's return value and storing it somewhere, which would complicate the code, you could use `getpeername' when building the request. I'm interested in this because I wrote a procedure that creates request objects from CGI requests, and I would like to make the meta information compatible. 4) `sanitize-response' adds a default charset parameter to the response's content-type header when the body is a string or a procedure, even if the content-type is not textual. See the code below. I think it should only do this for textual content-types (text/*). Regards ### `sanitize-response' test (use-modules (web server) (web request) (web response) (web uri) (rnrs io ports)) (define (sanitize-response-test body) (call-with-values (lambda () (sanitize-response (build-request (string->uri "http://test/")) '((content-type . (application/octet-stream))) body)) (lambda (response body) (values (response-headers response) body)))) (sanitize-response-test (lambda (port) (put-bytevector port #vu8(1 2 3)))) => ((content-length . 3) (content-type application/octet-stream (charset . "utf-8"))) => #vu8(1 2 3) (sanitize-response-test "\x01\x02\x03") => ((content-length . 3) (content-type application/octet-stream (charset . "utf-8"))) => #vu8(1 2 3) (sanitize-response-test #vu8(1 2 3)) => ((content-length . 3) (content-type application/octet-stream)) => #vu8(1 2 3)