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):
<html><body> <form method='POST' action='cgi-bin/login.py'> <input type='text' name='userid'> <input type='password' name='userpwd'> <input type='submit' value='Login'> <input type='hidden' name='cmd' value='view'> </form> </body></html>
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!
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 z_axis@163.com wrote:
The hunchentoot-cgi basically works with hunchentoot-1.2.2 now with a few modification:
- 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):
<html><body> <form method='POST' action='cgi-bin/login.py'> <input type='text' name='userid'> <input type='password' name='userpwd'> <input type='submit' value='Login'> <input type='hidden' name='cmd' value='view'> </form> </body></html>
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@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
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 hans.huebner@gmail.com 写道:
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 z_axis@163.com wrote:
The hunchentoot-cgi basically works with hunchentoot-1.2.2 now with a few modification:
- 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):
<html><body> <form method='POST' action='cgi-bin/login.py'> <input type='text' name='userid'> <input type='password' name='userpwd'> <input type='submit' value='Login'> <input type='hidden' name='cmd' value='view'> </form> </body></html>
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@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
On Mon, Jan 9, 2012 at 8:21 AM, z_axis z_axis@163.com 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 hans.huebner@gmail.com 写道:
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 z_axis@163.com wrote:
The hunchentoot-cgi basically works with hunchentoot-1.2.2 now with a few modification:
- 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):
<html><body> <form method='POST' action='cgi-bin/login.py'> <input type='text' name='userid'> <input type='password' name='userpwd'> <input type='submit' value='Login'> <input type='hidden' name='cmd' value='view'> </form> </body></html>
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@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
-- 使用 Opera 革命性的电子邮件客户程序: http://www.opera.com/mail/
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
Quoth z_axis z_axis@163.com:
#'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
On Tue, Jan 10, 2012 at 11:21 AM, Sebastian Tennant sebyte@smolny.plus.com 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
On Tue, Jan 10, 2012 at 11:21 AM, Sebastian Tennant sebyte@smolny.plus.com 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.
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 sebyte@smolny.plus.com 写道:
Quoth z_axis z_axis@163.com:
#'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@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
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 z_axis@163.com 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 sebyte@smolny.plus.com 写道:
Quoth z_axis z_axis@163.com:
#'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@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
-- 使用 Opera 革命性的电子邮件客户程序: http://www.opera.com/mail/
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
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 hans.huebner@gmail.com 写道:
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 z_axis@163.com 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 sebyte@smolny.plus.com 写道:
Quoth z_axis z_axis@163.com:
#'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@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
-- 使用 Opera 革命性的电子邮件客户程序: http://www.opera.com/mail/
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel