From patrick.may at mac.com Mon Jan 2 22:42:14 2012 From: patrick.may at mac.com (Patrick May) Date: Mon, 02 Jan 2012 17:42:14 -0500 Subject: [hunchentoot-devel] Ediware packages missing from Git Message-ID: <6578E0D6-EF87-4178-BF04-D1F2FE988086@mac.com> Are there any plans to add puri (used by drakma) and trivial-gray-streams (used by chunga and flexi-streams) to the git repository so that all required packages are available in one spot? (Yes, I know that cxml and uffi, used by cl-webdav and cl-gd respectively, are also not in Git, but I'm primarily using Hunchentoot, cl-who, and Drakma.) Regards, Patrick From hans.huebner at gmail.com Tue Jan 3 07:04:04 2012 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Tue, 3 Jan 2012 08:04:04 +0100 Subject: [hunchentoot-devel] Ediware packages missing from Git In-Reply-To: <6578E0D6-EF87-4178-BF04-D1F2FE988086@mac.com> References: <6578E0D6-EF87-4178-BF04-D1F2FE988086@mac.com> Message-ID: Hi Patrick, On Mon, Jan 2, 2012 at 11:42 PM, Patrick May wrote: > ? ? ? ?Are there any plans to add puri (used by drakma) and trivial-gray-streams (used by chunga and flexi-streams) to the git repository so that all required packages are available in one spot? ?(Yes, I know that cxml and uffi, used by cl-webdav and cl-gd respectively, are also not in Git, but I'm primarily using Hunchentoot, cl-who, and Drakma.) I have no plans to include third-party libraries in the edicl repository - I am using quicklisp to install dependencies and recommend that as the preferred method for users. Best regards, Hans From stefan-ml at snobis.de Sun Jan 8 16:33:02 2012 From: stefan-ml at snobis.de (Stefan Nobis) Date: Sun, 08 Jan 2012 17:33:02 +0100 Subject: [hunchentoot-devel] Problems with big uploads Message-ID: Hi. I have written a small and very simple web-service to which I want to upload files. With the current version 1.2.1 of hunchentoot I have problems uploading big files, say 1GB. As far as I remeber, with older versions (1.0 and 1.1) big uploads worked well. Basically the following code is in use: --8<---------------cut here---------------start------------->8--- (hunchentoot:define-easy-handler (handle-upload :uri "/path/to/upload-service") () (let ((uploaded (when (and (boundp 'hunchentoot:*request*) (hunchentoot:post-parameter "filename")) (handle-file (hunchentoot:post-parameter "filename"))))) (generate-html-code))) --8<---------------cut here---------------end--------------->8--- And handle-file looks like this: --8<---------------cut here---------------start------------->8--- (defun handle-file (post-parameter) (ht-log :info "Handling file upload with params: '~A'." post-parameter) (when (and post-parameter (listp post-parameter)) (destructuring-bind (path filename content-type) post-parameter (declare (ignore content-type)) ;; strip directory info send by Windows browsers (when (search "Windows" (hunchentoot:user-agent) :test #'char-equal) (setf filename (ppcre:regex-replace ".*\\\\" filename ""))) (fad:copy-file path (ensure-directories-exist (merge-pathnames filename *unsecure-upload-dir*)) :overwrite t) filename))) --8<---------------cut here---------------end--------------->8--- It seems that hunchentoot tries to read the whole stream into memory and that the heap is too small (the server has only 1GB RAM and the heap of the sbcl process is limited to about 600MB). Is there any (easy) way to let hunchentoot load the data in small chunks in order to limit the maximal amount of memory used, independent of the file size? -- Until the next mail..., Stefan. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 454 bytes Desc: not available URL: From hans.huebner at gmail.com Sun Jan 8 17:13:47 2012 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Sun, 8 Jan 2012 18:13:47 +0100 Subject: [hunchentoot-devel] Problems with big uploads In-Reply-To: References: Message-ID: Stefan, On Sun, Jan 8, 2012 at 5:33 PM, Stefan Nobis wrote: > It seems that hunchentoot tries to read the whole stream into memory > and that the heap is too small (the server has only 1GB RAM and the > heap of the sbcl process is limited to about 600MB). What makes you think so? I am not saying that it is not possible, but as Hunchentoot uses the RFC2388 library for parsing uploads and I think that library has not recently changed, I wonder how you determined that your uploads are actually read into memory. What did you do to decide that this would be the problem? -Hans From z_axis at 163.com Mon Jan 9 02:14:45 2012 From: z_axis at 163.com (z_axis) Date: Mon, 09 Jan 2012 10:14:45 +0800 Subject: [hunchentoot-devel] Why can't the python script get the post parameters from hunchentoot-cgi? Message-ID: The hunchentoot-cgi basically works with hunchentoot-1.2.2 now with a few modification: 1. In #'handle-cgi-script, replacing :external-format tbnl::+latin-1+ with :external-format tbnl::+utf-8+ 2. As WhiteCat suggested, use #'make-pathname as below: (pushnew (hunchentoot-cgi::create-cgi-dispatcher-and-handler "/cgi-bin/" (make-pathname :directory '(:absolute "media" "E" "myapp" "cgi-bin"))) dispatch-table :test #'equal) However, I do not understand why the python script cannot get the POSTed parameter, i.e., when visiting http://127.0.0:8000/cgi-bin/login.py?cmd=view, login.py can get the parameter cmd's value sucessfully, but when posted by the following form, login.py cannot get all the posted values (no matter hidden or not):
I guess hunchentoot-cgi does not pass the posted parameter(s) to the python script according to the environment: GET http://127.0.0.1:8000/cgi-bin/nav.py?userid=xyz&cmd=view (SERVER_SOFTWARE=hunchentoot/1.2.2 SERVER_NAME=127.0.0.1 GATEWAY_INTERFACE=CGI/1.1 SERVER_PROTOCOL=HTTP/1.1 SERVER_PORT=8000 REQUEST_METHOD=GET CONTENT_TYPE=text/html CONTENT_LENGTH=NIL SCRIPT_NAME=/cgi-bin/nav.py QUERY_STRING=userid=xyz&cmd=view REMOTE_ADDR=127.0.0.1 HTTP_HOST=NIL REQUEST_URI=/cgi-bin/nav.py?userid=xyz&cmd=view SERVER_ADDR=NIL HTTP_USER_AGENT=Mozilla/5.0 (X11; Linux i686; rv:9.0.1) Gecko/20100101 Firefox/9.0.1 HTTP_REFERER=http://127.0.0.1:8000/) POST to /cgi-bin/nav.py (SERVER_SOFTWARE=hunchentoot/1.2.2 SERVER_NAME=127.0.0.1 GATEWAY_INTERFACE=CGI/1.1 SERVER_PROTOCOL=HTTP/1.1 SERVER_PORT=8000 REQUEST_METHOD=POST CONTENT_TYPE=text/html CONTENT_LENGTH=NIL POST_PARAMETERS=((userid . xyz) (userpwd . 123) (cmd . view)) SCRIPT_NAME=/cgi-bin/nav.py QUERY_STRING=NIL REMOTE_ADDR=127.0.0.1 HTTP_HOST=NIL REQUEST_URI=/cgi-bin/nav.py SERVER_ADDR=NIL HTTP_USER_AGENT=Mozilla/5.0 (X11; Linux i686; rv:9.0.1) Gecko/20100101 Firefox/9.0.1 Please shed a light on me, thanks! From hans.huebner at gmail.com Mon Jan 9 07:01:28 2012 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Mon, 9 Jan 2012 08:01:28 +0100 Subject: [hunchentoot-devel] Why can't the python script get the post parameters from hunchentoot-cgi? In-Reply-To: References: Message-ID: Hi, hunchentoot-cgi is a package separate from Hunchentoot. The canonical location of it is https://github.com/slyrus/hunchentoot-cgi, so you can either report the problem as an issue or, better yet, fix it and send a pull request there. -Hans On Mon, Jan 9, 2012 at 3:14 AM, z_axis wrote: > The hunchentoot-cgi basically works with hunchentoot-1.2.2 now with a few > modification: > 1. In #'handle-cgi-script, replacing :external-format tbnl::+latin-1+ with > :external-format tbnl::+utf-8+ > 2. As WhiteCat suggested, use #'make-pathname as below: > > (pushnew (hunchentoot-cgi::create-cgi-dispatcher-and-handler > ? ? ? ? ?"/cgi-bin/" > ? ? ? ? ?(make-pathname :directory '(:absolute "media" "E" "myapp" > "cgi-bin"))) > ? ? ? ? dispatch-table :test #'equal) > > However, I do not understand why the python script cannot get the POSTed > parameter, > i.e., when visiting http://127.0.0:8000/cgi-bin/login.py?cmd=view, login.py > can get the parameter cmd's value sucessfully, > ?but when posted by the following form, login.py cannot get all the posted > values (no matter hidden or not): > > > ?
> ? ? > ? ? > ? ? > ? ? > ?
> > > I guess hunchentoot-cgi does not pass the posted parameter(s) to the python > script according to the environment: > > GET http://127.0.0.1:8000/cgi-bin/nav.py?userid=xyz&cmd=view > (SERVER_SOFTWARE=hunchentoot/1.2.2 > ?SERVER_NAME=127.0.0.1 GATEWAY_INTERFACE=CGI/1.1 > ?SERVER_PROTOCOL=HTTP/1.1 SERVER_PORT=8000 REQUEST_METHOD=GET > ?CONTENT_TYPE=text/html CONTENT_LENGTH=NIL > ?SCRIPT_NAME=/cgi-bin/nav.py QUERY_STRING=userid=xyz&cmd=view > ?REMOTE_ADDR=127.0.0.1 HTTP_HOST=NIL > ?REQUEST_URI=/cgi-bin/nav.py?userid=xyz&cmd=view SERVER_ADDR=NIL > ?HTTP_USER_AGENT=Mozilla/5.0 (X11; Linux i686; rv:9.0.1) Gecko/20100101 > Firefox/9.0.1 > ?HTTP_REFERER=http://127.0.0.1:8000/) > > > POST to /cgi-bin/nav.py > (SERVER_SOFTWARE=hunchentoot/1.2.2 > ?SERVER_NAME=127.0.0.1 GATEWAY_INTERFACE=CGI/1.1 > ?SERVER_PROTOCOL=HTTP/1.1 SERVER_PORT=8000 REQUEST_METHOD=POST > ?CONTENT_TYPE=text/html CONTENT_LENGTH=NIL > ?POST_PARAMETERS=((userid . xyz) (userpwd . 123) (cmd . view)) > ?SCRIPT_NAME=/cgi-bin/nav.py QUERY_STRING=NIL REMOTE_ADDR=127.0.0.1 > ?HTTP_HOST=NIL REQUEST_URI=/cgi-bin/nav.py SERVER_ADDR=NIL > ?HTTP_USER_AGENT=Mozilla/5.0 (X11; Linux i686; rv:9.0.1) Gecko/20100101 > Firefox/9.0.1 > > Please shed a light on me, thanks! > > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel From hans.huebner at gmail.com Mon Jan 9 07:19:51 2012 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Mon, 9 Jan 2012 08:19:51 +0100 Subject: [hunchentoot-devel] Problems with big uploads In-Reply-To: References: Message-ID: Stefan, I have verified that Hunchentoot does not read uploads into main memory by running the :hunchentoot-test server and using the "file uploads" test. I sent a 2GB file and noticed no increase in the working set size of the Lisp. The upload took too much time, though, and making the body parsing more efficient might be a worthy optimization target. Yet, it does not seem that Hunchentoot itself is responsible for your working set size problems, at least judging from this test. Can you isolate the problem and post a bit of code that'd allow us to reproduce it? -Hans From z_axis at 163.com Mon Jan 9 07:21:14 2012 From: z_axis at 163.com (z_axis) Date: Mon, 09 Jan 2012 15:21:14 +0800 Subject: [hunchentoot-devel] Why can't the python script get the post parameters from hunchentoot-cgi? In-Reply-To: References: Message-ID: I know this is a hunchentoot list.However, besides there is no hunchentoot-cgi mailing list, maybe this problem is relative to hunchentoot as hunchentoot-cgi call #'create-prefix-dispatcher in which hunchentoot doesnot prepare both content-type and content-length. ? Mon, 09 Jan 2012 15:01:28 +0800?Hans H?bner ??: > Hi, > > hunchentoot-cgi is a package separate from Hunchentoot. The canonical > location of it is https://github.com/slyrus/hunchentoot-cgi, so you > can either report the problem as an issue or, better yet, fix it and > send a pull request there. > > -Hans > > On Mon, Jan 9, 2012 at 3:14 AM, z_axis wrote: >> The hunchentoot-cgi basically works with hunchentoot-1.2.2 now with a >> few >> modification: >> 1. In #'handle-cgi-script, replacing :external-format tbnl::+latin-1+ >> with >> :external-format tbnl::+utf-8+ >> 2. As WhiteCat suggested, use #'make-pathname as below: >> >> (pushnew (hunchentoot-cgi::create-cgi-dispatcher-and-handler >> "/cgi-bin/" >> (make-pathname :directory '(:absolute "media" "E" "myapp" >> "cgi-bin"))) >> dispatch-table :test #'equal) >> >> However, I do not understand why the python script cannot get the POSTed >> parameter, >> i.e., when visiting http://127.0.0:8000/cgi-bin/login.py?cmd=view, >> login.py >> can get the parameter cmd's value sucessfully, >> but when posted by the following form, login.py cannot get all the >> posted >> values (no matter hidden or not): >> >> >>
>> >> >> >> >>
>> >> >> I guess hunchentoot-cgi does not pass the posted parameter(s) to the >> python >> script according to the environment: >> >> GET http://127.0.0.1:8000/cgi-bin/nav.py?userid=xyz&cmd=view >> (SERVER_SOFTWARE=hunchentoot/1.2.2 >> SERVER_NAME=127.0.0.1 GATEWAY_INTERFACE=CGI/1.1 >> SERVER_PROTOCOL=HTTP/1.1 SERVER_PORT=8000 REQUEST_METHOD=GET >> CONTENT_TYPE=text/html CONTENT_LENGTH=NIL >> SCRIPT_NAME=/cgi-bin/nav.py QUERY_STRING=userid=xyz&cmd=view >> REMOTE_ADDR=127.0.0.1 HTTP_HOST=NIL >> REQUEST_URI=/cgi-bin/nav.py?userid=xyz&cmd=view SERVER_ADDR=NIL >> HTTP_USER_AGENT=Mozilla/5.0 (X11; Linux i686; rv:9.0.1) Gecko/20100101 >> Firefox/9.0.1 >> HTTP_REFERER=http://127.0.0.1:8000/) >> >> >> POST to /cgi-bin/nav.py >> (SERVER_SOFTWARE=hunchentoot/1.2.2 >> SERVER_NAME=127.0.0.1 GATEWAY_INTERFACE=CGI/1.1 >> SERVER_PROTOCOL=HTTP/1.1 SERVER_PORT=8000 REQUEST_METHOD=POST >> CONTENT_TYPE=text/html CONTENT_LENGTH=NIL >> POST_PARAMETERS=((userid . xyz) (userpwd . 123) (cmd . view)) >> SCRIPT_NAME=/cgi-bin/nav.py QUERY_STRING=NIL REMOTE_ADDR=127.0.0.1 >> HTTP_HOST=NIL REQUEST_URI=/cgi-bin/nav.py SERVER_ADDR=NIL >> HTTP_USER_AGENT=Mozilla/5.0 (X11; Linux i686; rv:9.0.1) Gecko/20100101 >> Firefox/9.0.1 >> >> Please shed a light on me, thanks! >> >> >> _______________________________________________ >> tbnl-devel site list >> tbnl-devel at common-lisp.net >> http://common-lisp.net/mailman/listinfo/tbnl-devel > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel -- ?? Opera ????????????: http://www.opera.com/mail/ From hans.huebner at gmail.com Mon Jan 9 08:21:36 2012 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Mon, 9 Jan 2012 09:21:36 +0100 Subject: [hunchentoot-devel] Why can't the python script get the post parameters from hunchentoot-cgi? In-Reply-To: References: Message-ID: On Mon, Jan 9, 2012 at 8:21 AM, z_axis wrote: > I know this is a hunchentoot list.However, besides there is no > hunchentoot-cgi mailing list, maybe this problem is relative to hunchentoot > as hunchentoot-cgi call #'create-prefix-dispatcher in which hunchentoot > doesnot prepare both content-type and content-length. Again, please report this issue to the hunchentoot-cgi maintainers. The hunchentoot API has changed and hunchentoot-cgi needs to be fixed to cater for that, not the other way round. -Hans > > ? Mon, 09 Jan 2012 15:01:28 +0800?Hans H?bner ??: > > >> Hi, >> >> hunchentoot-cgi is a package separate from Hunchentoot. The canonical >> location of it is https://github.com/slyrus/hunchentoot-cgi, so you >> can either report the problem as an issue or, better yet, fix it and >> send a pull request there. >> >> -Hans >> >> On Mon, Jan 9, 2012 at 3:14 AM, z_axis wrote: >>> >>> The hunchentoot-cgi basically works with hunchentoot-1.2.2 now with a few >>> modification: >>> 1. In #'handle-cgi-script, replacing :external-format tbnl::+latin-1+ >>> with >>> :external-format tbnl::+utf-8+ >>> 2. As WhiteCat suggested, use #'make-pathname as below: >>> >>> (pushnew (hunchentoot-cgi::create-cgi-dispatcher-and-handler >>> "/cgi-bin/" >>> (make-pathname :directory '(:absolute "media" "E" "myapp" >>> "cgi-bin"))) >>> dispatch-table :test #'equal) >>> >>> However, I do not understand why the python script cannot get the POSTed >>> parameter, >>> i.e., when visiting http://127.0.0:8000/cgi-bin/login.py?cmd=view, >>> login.py >>> can get the parameter cmd's value sucessfully, >>> but when posted by the following form, login.py cannot get all the >>> posted >>> values (no matter hidden or not): >>> >>> >>>
>>> >>> >>> >>> >>>
>>> >>> >>> I guess hunchentoot-cgi does not pass the posted parameter(s) to the >>> python >>> script according to the environment: >>> >>> GET http://127.0.0.1:8000/cgi-bin/nav.py?userid=xyz&cmd=view >>> (SERVER_SOFTWARE=hunchentoot/1.2.2 >>> SERVER_NAME=127.0.0.1 GATEWAY_INTERFACE=CGI/1.1 >>> SERVER_PROTOCOL=HTTP/1.1 SERVER_PORT=8000 REQUEST_METHOD=GET >>> CONTENT_TYPE=text/html CONTENT_LENGTH=NIL >>> SCRIPT_NAME=/cgi-bin/nav.py QUERY_STRING=userid=xyz&cmd=view >>> REMOTE_ADDR=127.0.0.1 HTTP_HOST=NIL >>> REQUEST_URI=/cgi-bin/nav.py?userid=xyz&cmd=view SERVER_ADDR=NIL >>> HTTP_USER_AGENT=Mozilla/5.0 (X11; Linux i686; rv:9.0.1) Gecko/20100101 >>> Firefox/9.0.1 >>> HTTP_REFERER=http://127.0.0.1:8000/) >>> >>> >>> POST to /cgi-bin/nav.py >>> (SERVER_SOFTWARE=hunchentoot/1.2.2 >>> SERVER_NAME=127.0.0.1 GATEWAY_INTERFACE=CGI/1.1 >>> SERVER_PROTOCOL=HTTP/1.1 SERVER_PORT=8000 REQUEST_METHOD=POST >>> CONTENT_TYPE=text/html CONTENT_LENGTH=NIL >>> POST_PARAMETERS=((userid . xyz) (userpwd . 123) (cmd . view)) >>> SCRIPT_NAME=/cgi-bin/nav.py QUERY_STRING=NIL REMOTE_ADDR=127.0.0.1 >>> HTTP_HOST=NIL REQUEST_URI=/cgi-bin/nav.py SERVER_ADDR=NIL >>> HTTP_USER_AGENT=Mozilla/5.0 (X11; Linux i686; rv:9.0.1) Gecko/20100101 >>> Firefox/9.0.1 >>> >>> Please shed a light on me, thanks! >>> >>> >>> _______________________________________________ >>> tbnl-devel site list >>> tbnl-devel at common-lisp.net >>> http://common-lisp.net/mailman/listinfo/tbnl-devel >> >> >> _______________________________________________ >> tbnl-devel site list >> tbnl-devel at common-lisp.net >> http://common-lisp.net/mailman/listinfo/tbnl-devel > > > > -- > ?? Opera ????????????: http://www.opera.com/mail/ > > > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel From stefan-ml at snobis.de Mon Jan 9 18:14:00 2012 From: stefan-ml at snobis.de (Stefan Nobis) Date: Mon, 09 Jan 2012 19:14:00 +0100 Subject: [hunchentoot-devel] Problems with big uploads In-Reply-To: ("Hans =?utf-8?Q?H=C3=BCbner=22's?= message of "Mon, 9 Jan 2012 08:19:51 +0100") References: Message-ID: Hans H?bner writes: > I have verified that Hunchentoot does not read uploads into main > memory by running the :hunchentoot-test server and using the "file > uploads" test. Yes, correct. After quite a bit of testing it seems that either IE or the proxy server at the office causes the trouble. Using my home internet connection and Firefox, uploading to the public service works. Maybe the proxy server at the office has some limits configured. Sorry for the inconvenience. -- Until the next mail..., Stefan. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 454 bytes Desc: not available URL: From sebyte at smolny.plus.com Tue Jan 10 10:21:16 2012 From: sebyte at smolny.plus.com (Sebastian Tennant) Date: Tue, 10 Jan 2012 10:21:16 +0000 Subject: [hunchentoot-devel] Why can't the python script get the post parameters from hunchentoot-cgi? References: Message-ID: Quoth z_axis : > #'create-prefix-dispatcher [...] does not prepare both Content-Type and > Content-Length [headers]. I don't use #'create-prefix-dispatcher (so I can't quickly test your assertion directly) but I can confirm that #'create-regex-dispatcher (which I use all the time) prepares a Content-Type header but doesn't prepare a Content-Length header. Assuming #'create-prefix-dispatcher behaves in the same way, then your assertion is correct. Hans, my understanding of the nuts and bolts of HTTP is pretty limited. What are the benefits of sending a Content-Length header? Is this something Hunchentoot should perhaps do? Seb From hans.huebner at gmail.com Tue Jan 10 10:25:29 2012 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Tue, 10 Jan 2012 11:25:29 +0100 Subject: [hunchentoot-devel] Why can't the python script get the post parameters from hunchentoot-cgi? In-Reply-To: References: Message-ID: On Tue, Jan 10, 2012 at 11:21 AM, Sebastian Tennant wrote: > Hans, my understanding of the nuts and bolts of HTTP is pretty limited. ?What > are the benefits of sending a Content-Length header? ?Is this something > Hunchentoot should perhaps do? A Content-Length: header can only be set when the length of the content is known in advance, which is not generally the case for CGI scripts. -Hans From rwiker at gmail.com Tue Jan 10 14:24:47 2012 From: rwiker at gmail.com (Raymond Wiker) Date: Tue, 10 Jan 2012 15:24:47 +0100 Subject: [hunchentoot-devel] Problem with (setf (hunchentoot:reply-external-format*) ...) Message-ID: I have (finally!) updated my local installation of hunchentoot. Testing indicates that things work as expected, except for one thing: calling (setf (hunchentoot:reply-external-format*) ...) in a request handler causes the request to abort. This is probably not a big issue, since I probably don't need to set the external format (it appears to get the right value automatically). I'm reporting it here because it may actually be caused by a bug; alternatively, it could be that I'm doing something stupid, which would then be useful to know. The code snippet below works (after making an easy-acceptor). Removing the #+nil causes it to break. (hunchentoot:define-easy-handler (test :uri "/test") (foo) (setf (hunchentoot:content-type*) "text/plain") #+nil (setf (hunchentoot:reply-external-format*) :utf-8) (format nil "Host: ~a~%Proto: ~a (~a)~%Script: ~a~%requrl: ~a~%foo: ~a" (hunchentoot:host) (hunchentoot:server-protocol*) (type-of (hunchentoot:server-protocol*)) (hunchentoot:script-name*) (hunchentoot:request-uri*) foo)) From rwiker at gmail.com Tue Jan 10 14:27:21 2012 From: rwiker at gmail.com (Raymond Wiker) Date: Tue, 10 Jan 2012 15:27:21 +0100 Subject: [hunchentoot-devel] Problem with (setf (hunchentoot:reply-external-format*) ...) In-Reply-To: References: Message-ID: Update: I checked the value of hunchentoot:*hunchentoot-default-external-format*, which gave me a hint that I needed to pass something else than just a keyword symbol... (setf (hunchentoot:reply-external-format*) (flexi-streams:make-external-format :utf-8)) appears to work. In case it matters: this is using Lispworks 6.0.1 (Professional, 32-bit) under Windows 7. On Tue, Jan 10, 2012 at 3:24 PM, Raymond Wiker wrote: > I have (finally!) updated my local installation of hunchentoot. > Testing indicates that things work as expected, except for one thing: > calling > (setf (hunchentoot:reply-external-format*) ...) in a request handler > causes the request to abort. This is probably not a big issue, since I > probably don't need to set the external format (it appears to get the > right value automatically). > > I'm reporting it here because it may actually be caused by a bug; > alternatively, it could be that I'm doing something stupid, which > would then be useful to know. > > The code snippet below works (after making an easy-acceptor). Removing > the #+nil causes it to break. > > (hunchentoot:define-easy-handler > ? ?(test :uri "/test") > ? ?(foo) > ?(setf (hunchentoot:content-type*) "text/plain") > ?#+nil (setf (hunchentoot:reply-external-format*) :utf-8) > ?(format nil "Host: ~a~%Proto: ~a (~a)~%Script: ~a~%requrl: ~a~%foo: ~a" > ? ? ? ? ?(hunchentoot:host) > ? ? ? ? ?(hunchentoot:server-protocol*) > ? ? ? ? ?(type-of (hunchentoot:server-protocol*)) > ? ? ? ? ?(hunchentoot:script-name*) > ? ? ? ? ?(hunchentoot:request-uri*) > ? ? ? ? ?foo)) From hans.huebner at gmail.com Tue Jan 10 14:34:01 2012 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Tue, 10 Jan 2012 15:34:01 +0100 Subject: [hunchentoot-devel] Problem with (setf (hunchentoot:reply-external-format*) ...) In-Reply-To: References: Message-ID: Hello Raymond, can you let us know what you mean by "abort". An error message and backtrace would be most helpful. Thanks, Hans On Tue, Jan 10, 2012 at 3:27 PM, Raymond Wiker wrote: > Update: I checked the value of > hunchentoot:*hunchentoot-default-external-format*, which gave me a > hint that I needed to pass something else than just a keyword > symbol... > > (setf (hunchentoot:reply-external-format*) > (flexi-streams:make-external-format :utf-8)) > > appears to work. > > In case it matters: this is using Lispworks 6.0.1 (Professional, > 32-bit) under Windows 7. > > On Tue, Jan 10, 2012 at 3:24 PM, Raymond Wiker wrote: >> I have (finally!) updated my local installation of hunchentoot. >> Testing indicates that things work as expected, except for one thing: >> calling >> (setf (hunchentoot:reply-external-format*) ...) in a request handler >> causes the request to abort. This is probably not a big issue, since I >> probably don't need to set the external format (it appears to get the >> right value automatically). >> >> I'm reporting it here because it may actually be caused by a bug; >> alternatively, it could be that I'm doing something stupid, which >> would then be useful to know. >> >> The code snippet below works (after making an easy-acceptor). Removing >> the #+nil causes it to break. >> >> (hunchentoot:define-easy-handler >> ? ?(test :uri "/test") >> ? ?(foo) >> ?(setf (hunchentoot:content-type*) "text/plain") >> ?#+nil (setf (hunchentoot:reply-external-format*) :utf-8) >> ?(format nil "Host: ~a~%Proto: ~a (~a)~%Script: ~a~%requrl: ~a~%foo: ~a" >> ? ? ? ? ?(hunchentoot:host) >> ? ? ? ? ?(hunchentoot:server-protocol*) >> ? ? ? ? ?(type-of (hunchentoot:server-protocol*)) >> ? ? ? ? ?(hunchentoot:script-name*) >> ? ? ? ? ?(hunchentoot:request-uri*) >> ? ? ? ? ?foo)) > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel From rwiker at gmail.com Tue Jan 10 15:40:17 2012 From: rwiker at gmail.com (Raymond Wiker) Date: Tue, 10 Jan 2012 16:40:17 +0100 Subject: [hunchentoot-devel] Problem with (setf (hunchentoot:reply-external-format*) ...) In-Reply-To: References: Message-ID: On Jan 10, 2012, at 15:34 , Hans H?bner wrote: > Hello Raymond, > > can you let us know what you mean by "abort". An error message and > backtrace would be most helpful. > > Thanks, > Hans That's the problem - I don't get an error message, and no stacktrace - the closest I get to an error indication is the web browser saying "the server dropped the connection" or something like that... I guess that could be a mismatch between content-length and actual content? Caused by different ideas of what the line-ending protocol is? I'll make a more concentrated effort to find out where it fails. From hans.huebner at gmail.com Tue Jan 10 15:44:53 2012 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Tue, 10 Jan 2012 16:44:53 +0100 Subject: [hunchentoot-devel] Problem with (setf (hunchentoot:reply-external-format*) ...) In-Reply-To: References: Message-ID: You may want to use HUNCHENTOOT:*CATCH-ERRORS-P* and/or CL:*BREAK-ON-SIGNALS* to get more information about the error. -HAns On Tue, Jan 10, 2012 at 4:40 PM, Raymond Wiker wrote: > On Jan 10, 2012, at 15:34 , Hans H?bner wrote: >> Hello Raymond, >> >> can you let us know what you mean by "abort". ?An error message and >> backtrace would be most helpful. >> >> Thanks, >> Hans > > > That's the problem - I don't get an error message, and no stacktrace - the closest I get to an error indication is the web browser saying "the server dropped the connection" or something like that... I guess that could be a mismatch between content-length and actual content? Caused by different ideas of what the line-ending protocol is? > > I'll make a more concentrated effort to find out where it fails. > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel From rwiker at gmail.com Tue Jan 10 16:18:12 2012 From: rwiker at gmail.com (Raymond Wiker) Date: Tue, 10 Jan 2012 17:18:12 +0100 Subject: [hunchentoot-devel] Problem with (setf (hunchentoot:reply-external-format*) ...) In-Reply-To: References: Message-ID: <7B572C0A-A46E-434C-A189-61EACF84DE76@gmail.com> On Jan 10, 2012, at 16:44 , Hans H?bner wrote: > You may want to use HUNCHENTOOT:*CATCH-ERRORS-P* and/or > CL:*BREAK-ON-SIGNALS* to get more information about the error. On a fresh Lispworks instance, on my MacBook, I get a heap of messages like [2012-01-10 17:13:59 [ERROR]] Error while processing connection: No applicable methods for # with args (:UTF8) --- sooo, it appears that Hunchentoot is only prepared to accept a flexi-streams:external-format, and not just a keyword symbol. I have the explanation I needed, and at least two acceptable fixes :-) Thanks, and sorry for the noise. From edi at weitz.de Tue Jan 10 16:23:04 2012 From: edi at weitz.de (Edi Weitz) Date: Tue, 10 Jan 2012 17:23:04 +0100 Subject: [hunchentoot-devel] Why can't the python script get the post parameters from hunchentoot-cgi? In-Reply-To: References: Message-ID: On Tue, Jan 10, 2012 at 11:21 AM, Sebastian Tennant wrote: > I don't use #'create-prefix-dispatcher (so I can't quickly test your assertion > directly) but I can confirm that #'create-regex-dispatcher (which I use all the > time) prepares a Content-Type header but doesn't prepare a Content-Length > header. > > Assuming #'create-prefix-dispatcher behaves in the same way, then your > assertion is correct. What's in these headers is orthogonal to what the dispatchers do. From z_axis at 163.com Tue Jan 10 23:53:35 2012 From: z_axis at 163.com (z_axis) Date: Wed, 11 Jan 2012 07:53:35 +0800 Subject: [hunchentoot-devel] Why can't the python script get the post parameters from hunchentoot-cgi? In-Reply-To: References: Message-ID: I have used `python -m CGIHTTPServer` to test the posted parameter: {'SERVER_PROTOCOL': 'HTTP/1.0', 'SERVER_SOFTWARE': 'SimpleHTTP/0.6 Python/2.7.2', 'SCRIPT_NAME': '/cgi-bin/nav.py', 'QUERY_STRING': '', 'SERVER_NAME': 'myarch', 'REMOTE_ADDR': '127.0.0.1', 'CONTENT_LENGTH': '33','HTTP_REFERER': 'http://127.0.0.1:8000/', 'SERVER_PORT': '8000', 'CONTENT_TYPE': 'application/x-www-form-urlencoded', 'HTTP_USER_AGENT': 'Mozilla/5.0 (X11; Linux i686; rv:9.0.1) Gecko/20100101 Firefox/9.0.1', '_': '/usr/bin/python', 'HTTP_ACCEPT': ' text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\r\n','GATEWAY_INTERFACE': 'CGI/1.1', 'REQUEST_METHOD': 'POST', 'REMOTE_HOST': 'localhost.localdomain', 'HTTP_COOKIE': '', 'PATH_INFO': ''} Both content_length and content_length are different from hunchentoot. ? Tue, 10 Jan 2012 18:21:16 +0800?Sebastian Tennant ??: > Quoth z_axis : >> #'create-prefix-dispatcher [...] does not prepare both Content-Type and >> Content-Length [headers]. > > I don't use #'create-prefix-dispatcher (so I can't quickly test your > assertion > directly) but I can confirm that #'create-regex-dispatcher (which I use > all the > time) prepares a Content-Type header but doesn't prepare a Content-Length > header. > > Assuming #'create-prefix-dispatcher behaves in the same way, then your > assertion is correct. > > Hans, my understanding of the nuts and bolts of HTTP is pretty limited. > What > are the benefits of sending a Content-Length header? Is this something > Hunchentoot should perhaps do? > > Seb > > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel -- ?? Opera ????????????: http://www.opera.com/mail/ From hans.huebner at gmail.com Wed Jan 11 06:37:01 2012 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Wed, 11 Jan 2012 07:37:01 +0100 Subject: [hunchentoot-devel] Why can't the python script get the post parameters from hunchentoot-cgi? In-Reply-To: References: Message-ID: Oops, the content-length of request bodies is certainly not variable when it is completely read by the web server, which would be the case for most CGI requests. So please disregard my previous comment. If you want to move this further, you'll need to either discuss with Cyrus Harmon (hunchentoot-cgi's author) or try to fix the problem yourself. Please post observations you make about hunchentoot-cgi to the github issue that you have created, not this list. Thank you. Hans On Wed, Jan 11, 2012 at 12:53 AM, z_axis wrote: > I have used `python -m CGIHTTPServer` to test the posted parameter: > > {'SERVER_PROTOCOL': 'HTTP/1.0', 'SERVER_SOFTWARE': 'SimpleHTTP/0.6 > Python/2.7.2', 'SCRIPT_NAME': '/cgi-bin/nav.py', > 'QUERY_STRING': '', 'SERVER_NAME': 'myarch', 'REMOTE_ADDR': '127.0.0.1', > 'CONTENT_LENGTH': '33','HTTP_REFERER': 'http://127.0.0.1:8000/', > 'SERVER_PORT': '8000', > 'CONTENT_TYPE': 'application/x-www-form-urlencoded', > 'HTTP_USER_AGENT': 'Mozilla/5.0 (X11; Linux i686; rv:9.0.1) Gecko/20100101 > Firefox/9.0.1', '_': '/usr/bin/python', > 'HTTP_ACCEPT': ' > text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\r\n','GATEWAY_INTERFACE': > 'CGI/1.1', > 'REQUEST_METHOD': 'POST', 'REMOTE_HOST': 'localhost.localdomain', > 'HTTP_COOKIE': '', 'PATH_INFO': ''} > > Both content_length and content_length are different from hunchentoot. > > > ? Tue, 10 Jan 2012 18:21:16 +0800?Sebastian Tennant > ??: > > >> Quoth z_axis : >>> >>> #'create-prefix-dispatcher [...] does not prepare both Content-Type and >>> Content-Length [headers]. >> >> >> I don't use #'create-prefix-dispatcher (so I can't quickly test your >> assertion >> directly) but I can confirm that #'create-regex-dispatcher (which I use >> all the >> time) prepares a Content-Type header but doesn't prepare a Content-Length >> header. >> >> Assuming #'create-prefix-dispatcher behaves in the same way, then your >> assertion is correct. >> >> Hans, my understanding of the nuts and bolts of HTTP is pretty limited. >> What >> are the benefits of sending a Content-Length header? Is this something >> Hunchentoot should perhaps do? >> >> Seb >> >> >> _______________________________________________ >> tbnl-devel site list >> tbnl-devel at common-lisp.net >> http://common-lisp.net/mailman/listinfo/tbnl-devel > > > > -- > ?? Opera ????????????: http://www.opera.com/mail/ > > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel From z_axis at 163.com Wed Jan 11 08:10:43 2012 From: z_axis at 163.com (z_axis) Date: Wed, 11 Jan 2012 16:10:43 +0800 Subject: [hunchentoot-devel] Why can't the python script get the post parameters from hunchentoot-cgi? In-Reply-To: References: Message-ID: I have contacted Cyrus Harmon for help. But I got no answer. Up to now i know hunchentoot has prepared post-parameters well. And i added the following line to hunchentoot-cgi to get right environment: ("CONTENT_TYPE" . ,(header-in :content-type *request*)) ("CONTENT_LENGTH" . ,(parse-integer (header-in :content-length *request*))) The environment passed to python script is as below: SERVER_SOFTWARE=hunchentoot/1.2.2 SERVER_NAME=127.0.0.1 GATEWAY_INTERFACE=CGI/1.1 SERVER_PROTOCOL=HTTP/1.1 SERVER_PORT=8000 REQUEST_METHOD=POST SCRIPT_NAME=/cgi-bin/nav.py QUERY_STRING=NIL CONTENT_TYPE=application/x-www-form-urlencoded CONTENT_LENGTH=31 POST_PARAMETERS=((userid . xyz) (userpwd . 123) (cmd . view)) PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/home/sw2wolf/bin REMOTE_ADDR=127.0.0.1 HTTP_HOST=NIL REQUEST_URI=/cgi-bin/nav.py SERVER_ADDR=NIL HTTP_USER_AGENT=Opera/9.80 (X11; FreeBSD 8.2-RELEASE i386; U; zh-cn) Presto/2.10.229 Version/11.60 HTTP_REFERER=http://127.0.0.1:8000/ But the python script still cannot get the posted parameters: ((userid . xyz) (userpwd . 123) (cmd . view)). Having a look at the #'maybe-read-post-parameters in request.lisp, it seems hunchentoot doesnot write the posted parameters to *STANDARD_IN* ? Sorry to disturb all of you, i will continue to wait for Cyrus Harmon's answer ... ? Wed, 11 Jan 2012 14:37:01 +0800?Hans H?bner ??: > Oops, the content-length of request bodies is certainly not variable > when it is completely read by the web server, which would be the case > for most CGI requests. So please disregard my previous comment. > > If you want to move this further, you'll need to either discuss with > Cyrus Harmon (hunchentoot-cgi's author) or try to fix the problem > yourself. Please post observations you make about hunchentoot-cgi to > the github issue that you have created, not this list. > > Thank you. > Hans > > On Wed, Jan 11, 2012 at 12:53 AM, z_axis wrote: >> I have used `python -m CGIHTTPServer` to test the posted parameter: >> >> {'SERVER_PROTOCOL': 'HTTP/1.0', 'SERVER_SOFTWARE': 'SimpleHTTP/0.6 >> Python/2.7.2', 'SCRIPT_NAME': '/cgi-bin/nav.py', >> 'QUERY_STRING': '', 'SERVER_NAME': 'myarch', 'REMOTE_ADDR': '127.0.0.1', >> 'CONTENT_LENGTH': '33','HTTP_REFERER': 'http://127.0.0.1:8000/', >> 'SERVER_PORT': '8000', >> 'CONTENT_TYPE': 'application/x-www-form-urlencoded', >> 'HTTP_USER_AGENT': 'Mozilla/5.0 (X11; Linux i686; rv:9.0.1) >> Gecko/20100101 >> Firefox/9.0.1', '_': '/usr/bin/python', >> 'HTTP_ACCEPT': ' >> text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\r\n','GATEWAY_INTERFACE': >> 'CGI/1.1', >> 'REQUEST_METHOD': 'POST', 'REMOTE_HOST': 'localhost.localdomain', >> 'HTTP_COOKIE': '', 'PATH_INFO': ''} >> >> Both content_length and content_length are different from hunchentoot. >> >> >> ? Tue, 10 Jan 2012 18:21:16 +0800?Sebastian Tennant >> >> ??: >> >> >>> Quoth z_axis : >>>> >>>> #'create-prefix-dispatcher [...] does not prepare both Content-Type >>>> and >>>> Content-Length [headers]. >>> >>> >>> I don't use #'create-prefix-dispatcher (so I can't quickly test your >>> assertion >>> directly) but I can confirm that #'create-regex-dispatcher (which I use >>> all the >>> time) prepares a Content-Type header but doesn't prepare a >>> Content-Length >>> header. >>> >>> Assuming #'create-prefix-dispatcher behaves in the same way, then your >>> assertion is correct. >>> >>> Hans, my understanding of the nuts and bolts of HTTP is pretty limited. >>> What >>> are the benefits of sending a Content-Length header? Is this something >>> Hunchentoot should perhaps do? >>> >>> Seb >>> >>> >>> _______________________________________________ >>> tbnl-devel site list >>> tbnl-devel at common-lisp.net >>> http://common-lisp.net/mailman/listinfo/tbnl-devel >> >> >> >> -- >> ?? Opera ????????????: http://www.opera.com/mail/ >> >> >> _______________________________________________ >> tbnl-devel site list >> tbnl-devel at common-lisp.net >> http://common-lisp.net/mailman/listinfo/tbnl-devel > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel -- ?? Opera ????????????: http://www.opera.com/mail/ From z_axis at 163.com Fri Jan 13 06:54:47 2012 From: z_axis at 163.com (z_axis) Date: Fri, 13 Jan 2012 14:54:47 +0800 Subject: [hunchentoot-devel] What does +latin-1+ means ? Message-ID: Can we use +utf-8+ instead of +latin-1+ in handler ? It is a newbie question but the following code doesnot work using +latin-1+: (let ((out (flexi-streams:make-flexi-stream (tbnl:send-headers) :external-format tbnl::+utf-8+))) ; tbnl::+;latin-1+ doesnot work (copy-stream in out 'character)) where, "in" holds utf-8 data. In hunchentoot-1.2.2, it says that +latin-1+ is "A FLEXI-STREAMS external format used for `faithful' input and output of binary data.", which i cannot understand very well. Sincerely! From divanov11 at gmail.com Thu Jan 19 12:12:09 2012 From: divanov11 at gmail.com (Dmitriy Ivanov) Date: Thu, 19 Jan 2012 16:12:09 +0400 Subject: [hunchentoot-devel] Error on LWW 4.4.6: -1 cannot be converted to foreign type (:UNSIGNED-INTEGER-TYPE 32). Message-ID: Hello folks, I have bumped into the error while playing around: 1. (hunchentoot:start (make-instance 'hunchentoot:easy-acceptor :port 4242 :write-timeout nil)) ; for lispworks4 2. Browsing results from test-handlers.lisp. It worked fine until I made a break for half an hour. When I come back to my computer and click on some link, LispWorks signaled. The odd thing is that in call to COMM::LISTEN-AND-ATTACH-STREAM-FROM-SOCKET, COMM::SOCKET : 464 But in call to (METHOD HUNCHENTOOT:CREATE-REQUEST-HANDLER-THREAD (HUNCHENTOOT:ONE-THREAD-PER-CONNECTION-TASKMASTER T)) HUNCHENTOOT::SOCKET : -1 Looks like LispWorks (or even Windows) error. Has anybody observed something like this? The backtrace excerpt is below. --------------------------------------------------- Condition: -1 cannot be converted to foreign type (:UNSIGNED-INTEGER-TYPE 32). Call to (SUBFUNCTION 2 COMM:START-UP-SERVER) (offset 43) COMM::SOCKET : NIL CONDITION : # Call to (SUBFUNCTION 1 COMM::LISTEN-AND-ATTACH-STREAM-NO-ERROR) (offset 41) CONDITION : # Binding frame: CONDITIONS::*IN-SIGNAL-CATCH* : T Call to SIGNAL (offset 699) CONDITIONS::DATUM : # CONDITIONS::ARGUMENTS : NIL Binding frame: CONDITIONS::*IN-SIGNAL-CATCH* : NIL Catch frame: CONDITIONS::SIGNAL-CATCH Binding frame: CONDITIONS::*BROKEN-ON-SIGNALS* : NIL Catch frame: # Binding frame: FLI::*FOREIGN-OBJECT-SCOPE-STACK-DETAILS* : #(16 #1=(8519856 . 4096) (#1#)) Call to COMM::GETPEERNAME (offset 227) COMM::S : -1 COMM::NAME : # COMM::NAMELEN : 16 Catch frame: # Binding frame: FLI::*FOREIGN-OBJECT-SCOPE-STACK-DETAILS* : #(0 NIL NIL) Call to COMM::GET-SOCKET-ADDRESS-AUX (offset 370) COMM::SOCKET : -1 FUNCTION : COMM::GETPEERNAME Call to HUNCHENTOOT::GET-PEER-ADDRESS-AND-PORT (offset 43) HUNCHENTOOT::SOCKET : -1 Call to (METHOD HUNCHENTOOT:CREATE-REQUEST-HANDLER-THREAD (HUNCHENTOOT:ONE-THREAD-PER-CONNECTION-TASKMASTER T)) (offset 97) HUNCHENTOOT:TASKMASTER : # HUNCHENTOOT::SOCKET : -1 CLOS::.ISL. : :DONT-KNOW Catch frame: # Call to COMM::LISTEN-AND-ATTACH-STREAM-FROM-SOCKET (offset 133) COMM::SOCKET : 464 FUNCTION : # Catch frame: (NIL) Call to COMM::LISTEN-AND-ATTACH-STREAM (offset 619) FUNCTION : # COMM::SERVICE : 4242 COMM::ANNOUNCE : # COMM::BACKLOG : 5 COMM::ADDRESS : NIL Catch frame: (NIL) Call to COMM::LISTEN-AND-ATTACH-STREAM-NO-ERROR (offset 284) FUNCTION : # COMM::SERVICE : 4242 COMM::ANNOUNCE : # COMM::BACKLOG : 5 COMM::ADDRESS : NIL Catch frame: MP::PROCESS-TAG ... -- Sincerely, Dmitriy Ivanov lisp.ystok.ru From hans.huebner at gmail.com Thu Jan 19 12:36:14 2012 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Thu, 19 Jan 2012 13:36:14 +0100 Subject: [hunchentoot-devel] Error on LWW 4.4.6: -1 cannot be converted to foreign type (:UNSIGNED-INTEGER-TYPE 32). In-Reply-To: References: Message-ID: Apparently, Lispworks invokes the callback function for new incoming connections with a socket argument value of -1: (defmethod start-listening ((acceptor acceptor)) (multiple-value-bind (listener-process startup-condition) (comm:start-up-server :service (acceptor-port acceptor) :address (acceptor-address acceptor) :process-name (format nil "Hunchentoot listener \(~A:~A)" (or (acceptor-address acceptor) "*") (acceptor-port acceptor)) ;; this function is called once on startup - we ;; use it to check for errors :announce (lambda (socket &optional condition) (declare (ignore socket)) (when condition (error condition))) ;; this function is called whenever a connection ;; is made :function (lambda (handle) (unless (acceptor-shutdown-p acceptor) (handle-incoming-connection (acceptor-taskmaster acceptor) handle))) ;; wait until the acceptor was successfully started ;; or an error condition is returned :wait t) (when startup-condition (error startup-condition)) (mp:process-stop listener-process) (setf (acceptor-process acceptor) listener-process) (values))) I am not sure whether this is expected or legal. I'd ask the Lispworks folks about it. -Hans On Thu, Jan 19, 2012 at 1:12 PM, Dmitriy Ivanov wrote: > Hello folks, > > I have bumped into the error while playing around: > > 1. (hunchentoot:start (make-instance 'hunchentoot:easy-acceptor > ? ? ? :port 4242 > ? ? ? :write-timeout nil)) ; for lispworks4 > 2. Browsing results from test-handlers.lisp. > > It worked fine until I made a break for half an hour. When I come back to my > computer and click on some link, LispWorks signaled. > > The odd thing is that in call to > COMM::LISTEN-AND-ATTACH-STREAM-FROM-SOCKET, > ?COMM::SOCKET : 464 > > But in call to (METHOD HUNCHENTOOT:CREATE-REQUEST-HANDLER-THREAD > (HUNCHENTOOT:ONE-THREAD-PER-CONNECTION-TASKMASTER T)) > ?HUNCHENTOOT::SOCKET ? ?: -1 > > Looks like LispWorks (or even Windows) error. > Has anybody observed something like this? > > The backtrace excerpt is below. > --------------------------------------------------- > Condition: -1 cannot be converted to foreign type (:UNSIGNED-INTEGER-TYPE > 32). > > Call to (SUBFUNCTION 2 COMM:START-UP-SERVER) (offset 43) > ?COMM::SOCKET : NIL > ?CONDITION ? ?: # > > Call to (SUBFUNCTION 1 COMM::LISTEN-AND-ATTACH-STREAM-NO-ERROR) (offset 41) > ?CONDITION : # > > Binding frame: > ?CONDITIONS::*IN-SIGNAL-CATCH* : T > > Call to SIGNAL (offset 699) > ?CONDITIONS::DATUM ? ? : # > ?CONDITIONS::ARGUMENTS : NIL > > Binding frame: > ?CONDITIONS::*IN-SIGNAL-CATCH* : NIL > > Catch frame: CONDITIONS::SIGNAL-CATCH > > Binding frame: > ?CONDITIONS::*BROKEN-ON-SIGNALS* : NIL > > Catch frame: # > > Binding frame: > ?FLI::*FOREIGN-OBJECT-SCOPE-STACK-DETAILS* : #(16 #1=(8519856 . 4096) > (#1#)) > > Call to COMM::GETPEERNAME (offset 227) > ?COMM::S ? ? ? : -1 > ?COMM::NAME ? ?: # > ?COMM::NAMELEN : 16 > > Catch frame: # > > Binding frame: > ?FLI::*FOREIGN-OBJECT-SCOPE-STACK-DETAILS* : #(0 NIL NIL) > > Call to COMM::GET-SOCKET-ADDRESS-AUX (offset 370) > ?COMM::SOCKET : -1 > ?FUNCTION ? ? : COMM::GETPEERNAME > > Call to HUNCHENTOOT::GET-PEER-ADDRESS-AND-PORT (offset 43) > ?HUNCHENTOOT::SOCKET : -1 > > Call to (METHOD HUNCHENTOOT:CREATE-REQUEST-HANDLER-THREAD > (HUNCHENTOOT:ONE-THREAD-PER-CONNECTION-TASKMASTER T)) (offset 97) > ?HUNCHENTOOT:TASKMASTER : > # > ?HUNCHENTOOT::SOCKET ? ?: -1 > ?CLOS::.ISL. ? ? ? ? ? ?: :DONT-KNOW > > Catch frame: # > > Call to COMM::LISTEN-AND-ATTACH-STREAM-FROM-SOCKET (offset 133) > ?COMM::SOCKET : 464 > ?FUNCTION ? ? : # (HUNCHENTOOT:ACCEPTOR))) 22087F32> > > Catch frame: (NIL) > > Call to COMM::LISTEN-AND-ATTACH-STREAM (offset 619) > ?FUNCTION ? ? ? : # (HUNCHENTOOT:ACCEPTOR))) 22087F32> > ?COMM::SERVICE ?: 4242 > ?COMM::ANNOUNCE : # > ?COMM::BACKLOG ?: 5 > ?COMM::ADDRESS ?: NIL > > Catch frame: (NIL) > > Call to COMM::LISTEN-AND-ATTACH-STREAM-NO-ERROR (offset 284) > ?FUNCTION ? ? ? : # (HUNCHENTOOT:ACCEPTOR))) 22087F32> > ?COMM::SERVICE ?: 4242 > ?COMM::ANNOUNCE : # > ?COMM::BACKLOG ?: 5 > ?COMM::ADDRESS ?: NIL > > Catch frame: MP::PROCESS-TAG > ... > -- > Sincerely, > Dmitriy Ivanov > lisp.ystok.ru > > > > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel From divanov11 at gmail.com Tue Jan 24 15:29:05 2012 From: divanov11 at gmail.com (Dmitriy Ivanov) Date: Tue, 24 Jan 2012 19:29:05 +0400 Subject: [hunchentoot-devel] GET parameters and request external format Message-ID: Hello folks, OT1H, the charset and external format of a request are extracted from the Content-Type header and used to percent-decode post parameters in the function maybe-read-post-parameters. OTOH, get parameters are always 1) initialized in the method #, 2) percent-decoded using *hunchentoot-default-external-format*. That works fine when all pages of the site use a the same external format - just setting *hunchentoot-default-external-format* globally is enough. But if one wanted various pages to be in different formats, that could be inappropriate. For now, it is even buggy because within the current flexi-streams version, the decode error is not suppressed by following code: (let ((*substitution-char* #\?)) (form-url-encoded-list-to-alist (split "&" query-string))) I have bumped into all this while trying to process forms in the :windows-1251 external format. AFAIK, user agents percent-encode get parameters using in the charset specified in the previous server response. Without post parameters, user agents do not supply the charset in Content-Type as a rule. Thus only a Hunchentoot request handler can definitely know what the charset is actually. All that means that we should postpone retrieval of get parameters as far as possible. Maybe it is worth not to specify the :initform for the get-parameters slot and leave it unbound? Then we could initialize this slot with the following: (defmethod slot-unbound (class (request request) (slot-name (eql 'get-parameters))) (setf (slot-value request 'get-parameters) (form-url-encoded-list-to-alist (split "&" (query-string request)) (request-external-format request)))) The only question is how to compute such a request-external-format. Any takers? -- Sincerely, Dmitriy Ivanov lisp.ystok.ru