- tbnl-devel@common-lisp.net - mailman3.common-lisp.net

[hunchentoot-devel] time of webserver access
by Jens Teich 25 Feb '09

25 Feb '09

I want to print on my website the time of access <p>page created in 0.023s</p> How can I use (time ...) within hunchentoot::define-easy-handler? Or is there any other way to go? Jens

2 2

[hunchentoot-devel] New Version: Stop hangs // Problem with usocket
by Daniel Brunner 25 Feb '09

25 Feb '09

I started to test with Hunchentoot 1.0.0 too and I ran into the same problem with the hanging hunchentoot:stop. As mentioned by Hans I installed some erlier versions of usocket. None of the 0.3.* and the 0.4.0 versions I tested worked well. The hunchentoot:stop hangs until I make another request to the web server. Then the stop function terminates. Kind regards, Daniel.

2 1

Re: [hunchentoot-devel] Hunchentoot new release
by Vsevolod 20 Feb '09

20 Feb '09

On Thu, Feb 19, 2009 at 1:16 PM, Edi Weitz <edi(a)agharta.de> wrote: > On Thu, Feb 19, 2009 at 12:04 PM, Vsevolod <vseloved(a)gmail.com> wrote: > > > 1. Last year I've sent a patch to CL+SSL, that allows it to work with > > password-protected private key files. So the appropriate mention in the > docs > > can be removed. > > Thanks, didn't know that. But we'll have to change in ssl.lisp then, > right? Do you have a patch for that? I prepared the patch (it's a copy of how it works for me in the previous version). Basically, it's just an addition of a keyword parameter to the function call in ssl.lisp. It works without any problems with the previous version (for quite a long time now). With 1.0.0. I was as well able to create an acceptor and view the default page over SSL. NIL works for not encrypted key files. The diff it attached. Additionally, I want to report some problems, which I've encountered while testing vesrion 1.0.0. 1. I get USOCKET:CONNECTION-REFUSED-ERROR on (hunchentoot-test:test-hunchentoot "http://localhost:4240") (my lisp is SBCL 1.0.20. I've updated bordeux_threads, chunga to the latest versions. flexi-streams v.1.0.7 I was already using). 2. If I do everything manually (setf *server* (make-instance 'hunchentoot:acceptor :port 4242)) (hunchentoot:start *server*) returns. If I browse to the site there's a default page there. But (hunchentoot:stop *server*) hangs. Best regards, Vsevolod

3 7

[hunchentoot-devel] Maximum Request Size
by Volkan YAZICI 01 Feb '09

01 Feb '09

Hi, Here are two patches[1][2] for both flexi-streams and hunchentoot. First patch makes flexi-streams to signal a condition when stream BOUND gets exceeded -- documentation and tests are included. Second one uses freshly introduced flexi-streams feature to limit the maximum request size. The latter hunchentoot patch is not well tested, doesn't include any documentation, replaces (raw-post-data ...) call with (clear-input ...) to flush the input stream (thus, can have chunking and common lisp implementation/platform related problems). It appears to be working for me, I hope it would for you as well. Thanks Hans Huebner for his kindly helps and Edi Weitz for his uninterest in any effort. Regards. P.S. Enhancements are patched against the repositories located at http://bknr.net/svn/ediware address. [1] http://www.students.itu.edu.tr/~yazicivo/tmp/flexi-streams-bound-invalidati… [2] http://www.students.itu.edu.tr/~yazicivo/tmp/hunchentoot-request-size-limit…

10 18

[hunchentoot-devel] Is there any implementation of XML-RPC for Hunchentoot
by christoph.senjak＠web.de 30 Jan '09

30 Jan '09

Hello. Again a question. Is there already any Implementation of XML-RPC running on Hunchentoot. I only found S-XML-RPC so far, and it seems like it is using allegro serve. It may not be too hard to implement, but if it is already there, I dont want to do it. Greetings Christoph-Simon Senjak

2 2

[hunchentoot-devel] rfc2388: Handling of octets and strings is flawed
by Leslie P. Polzer 30 Jan '09

30 Jan '09

rfc2388 doesn't care about the encoding of strings despite of returning them. The result of a parsed body that doesn't contain binary data is then a vector of octets disguised as string, forcing the ultimate user to jump through this or a similar hoop: (sb-ext:octets-to-string (map '(vector (unsigned-byte 8)) #'char-int s)) Hunchentoot for example will just return this broken string when rfc2388 is used for parsing a parameter's content. IMO parse-mime should return a vector of octets and not a string. Its users (e.g. HT) should then apply appropriate character conversion functions to build a proper string. Leslie -- LinkedIn Profile: http://www.linkedin.com/in/polzer Xing Profile: https://www.xing.com/profile/LeslieP_Polzer Blog: http://blog.viridian-project.de/

2 3

[hunchentoot-devel] Changes in (send-headers) ?
by css 28 Jan '09

28 Jan '09

Hello. I havent used hunchentoot for a while now, so I checked out the svn-repository on http://bknr.net/svn/ediware/ (I hope this is the correct one) and Installed the packages. The server seems to work, but unfortunately, the following code seems not to do: (defun http-seite () (with-html-output (out (send-headers)) (:html (:head (:title "Hallo-Welt-Seite")) (:body (:h1 "Hallo Welt"))))) (setf *dispatch-table* (list (create-prefix-dispatcher "/hallo-welt" 'http-seite))) (defvar *server* (start-server :port 8000)) When calling http://localhost:8000/hallo-welt, I only get an empty page. For any other URL, i get a "not found" error. When defining the function differently, returning a string, say (defun http-seite () (with-html-output-to-string (bla) (:html (:head (:title "Hallo-Welt-Seite")) (:body (:h1 "Hallo Welt"))))) the whole thing works. Also the more trivial functions (defun http-2 () (write-char #\A (send-headers))) and (defun http-2 () (write-char #\A (send-headers)) (finish-output (send-headers))) do not produce any output. I read the included documentation, but it seems like (send-headers) hasnt changed its meening according to it, and also the code doesnt say anything else. Any Ideas what I could be doing wrong? Greetings Christoph

4 3

[hunchentoot-devel] CLEAR-INPUT and RAW-POST-DATA
by Volkan YAZICI 21 Jan '09

21 Jan '09

Hi, Why doesn't we use (clear-input *hunchentoot-stream*) instead of (raw-post-data :force-binary t) in the START-OUTPUT function in headers.lisp? Regards.

1 0

Re: [hunchentoot-devel] Widget Guidlines
by First name Last name 20 Jan '09

20 Jan '09

>> Hi >> I have been using hunchentoot for the last two months and I have created a >> DB-Grid widget for myself. I pass relevant info in through parameters like >> table name and columns to display and the widget generates a html grid with >> paging, edit/delete and search functionality. >Hi, >I believe that attempt for such standardization could be weblocks >(based on hunchentoot)... >http://weblocks.viridian-project.de/ >Best regards, >Tomek Lipski Tomek I think weblocks is a bit of a over kill. I have never used it but from what I saw in the documentation it is big and in my opinion might carry to much over head. I am sure it has its right full place but I am not sure this is it. What I was thinking about was free standing widgets that don't need a whole framework to carry them. A specification for something like this would include a list of common properties/functionality and general methodology (persistence,state...etc) that would fit in with hunchentoot's design and strong points. Regards Phil PS. Apologies for re-posting but I am still getting the hang of using the mailing list....for some reason the previous post lost the text (think it is because my web client wraps replies in table)

4 4

Re: [hunchentoot-devel] Widget Guidlines
by First name Last name 20 Jan '09

20 Jan '09

----- Original Message ------ From:Tomasz Lipski Sent:Tuesday, January 20, 2009 10:26 To:General interest list for Hunchentoot and CL-WEBDAV tbnl-devel(a)common-lisp.net; Subject:Re: [hunchentoot-devel] Widget Guidlines 2009/1/19 First name Last name : >> Hi >> I have been using hunchentoot for the last two months and I have created a >> DB-Grid widget for myself. I pass relevant info in through parameters like >> table name and columns to display and the widget generates a html grid with >> paging, edit/delete and search functionality. >Hi, >I believe that attempt for such standardization could be weblocks >(based on hunchentoot)... >http://weblocks.viridian-project.de/ >Best regards, >Tomek Lipski Tomek I think weblocks is a bit of a over kill. I have never used it but from what I saw in the documentation it is big and in my opinion might carry to much over head. I am sure it has its right full place but I am not sure this is it. What I was thinking about was free standing widgets that don't need a whole framework to carry them. A specification for something like this would include a list of common properties/functionality and general methadoligy (persistance,state...etc) that would fit in with hunchentoot's design and strong points. Regards Phil

1 0