tbnl-devel February 2009

tbnl-devel@common-lisp.net

16 participants
10 discussions

[hunchentoot-devel] New releases of Hunchentoot, Drakma, and Chunga
by Edi Weitz 09 Apr '09

09 Apr '09

Hi, I've just released new versions (all called 1.0.0) of Hunchentoot, Drakma, and Chunga. Note that none of these is compatible with earlier versions, so if you upgrade, you'll need to upgrade all of them. If you're using Hunchentoot or Drakma in a production environment and if it works well for you, you probably shouldn't switch. These are releases with a lot of changes and it is pretty likely that they contain bugs. If you're tracking the development, it'd be nice if you could download the new versions and provide feedback, though. The good news: * Hunchentoot has a new architecture that should hopefully make it much easier to extend or to customize it. * Both Huchentoot and Drakma should be faster now. * Now that we finally have release versions again, there are more things to come. Expect 1.0.1, 1.0.2, etc. releases in the next weeks. The bad news: * The Hunchentoot API has changed considerably and you'll have to read the documentation to see how it works now. Of course, we didn't do that to annoy you - we have to change our own web apps as well. We think that the new API is better, though, and that the change was worth it. * Some stuff has been removed, either because it seemed that nobody used it or because we thought it didn't really belong into a web server. Have fun, Edi.

10 31

[hunchentoot-devel] COMET with Hunchentoot?
by Jim Prewett 04 Mar '09

04 Mar '09

Hello, I'm not quite sure what I'm after except that the buzzword seems to be "COMET". AFAICT, much of the time, this involves having javascript send an XMLHttpRequest to the server which the server keeps open until there is data to be sent to the client. Has anyone done anything like this? Does anyone have thoughts on how one might implement something along these lines? All I am really after is some sort of "Server Push" - I'd be happy to hear any thoughts anyone has along these lines. Thanks, Jim James E. Prewett Jim(a)Prewett.org download(a)hpc.unm.edu Systems Team Leader LoGS: http://www.hpc.unm.edu/~download/LoGS/ Designated Security Officer OpenPGP key: pub 1024D/31816D93 HPC Systems Engineer III UNM HPC 505.277.8210

6 16

[hunchentoot-devel] hunchentoot errors
by Harrison Maseko 28 Feb '09

28 Feb '09

Hi all, I just installed Hunchentoot 1.0.0. When I do (hunchentoot:start (make-instance 'hunchentoot:acceptor :port 4242)) I get the following error: There is no applicable method for the generic function #<STANDARD-GENERIC-FUNCTION HUNCHENTOOT:START-LISTENING (0)> when called with arguments (#<HUNCHENTOOT:ACCEPTOR (host *, port 4242)>). [Condition of type SIMPLE-ERROR] 0: [DEFAULT-DEBUGGER] Use default debugger. 1: [ABORT] Return to SLIME's top level. 2: [CLOSE-CONNECTION] Close SLIME connection 3: [ABORT] Exit debugger, returning to top level. I don't understand this message and other similar errors that come up when I try to run the examples in the Hunchentoot documentation. I am a Lisp newbie running SBCL 1.0.6 via Cusp on Vista. Can you help? Harrison.

3 9

[hunchentoot-devel] *print-readably* et al.
by Leslie P. Polzer 27 Feb '09

27 Feb '09

bt:make-thread uses a funny table with custom bindings to initialize standardized globals like *print-readably*. This seriously interferes with applications using Hunchentoot. I have already posted to bordeaux-thread-devel stating that the new thread should probably inherit the values from the parent thread, but things are slow there I think. FYI we now have this in Weblocks to work around at least the aforementioned variable (which causes the biggest problem because a lot of ~S format directives suddenly become trip mines): (defmethod process-connection ((acceptor weblocks-acceptor) socket) (let ((*print-readably* nil)) (call-next-method))) Hunchentoot should probably provide a similar workaround until the thing is sorted out on the BT side. Other rebindings seem to be pretty harmless in comparison, but YMMV. :( Leslie -- LinkedIn Profile: http://www.linkedin.com/in/polzer Xing Profile: https://www.xing.com/profile/LeslieP_Polzer Blog: http://blog.viridian-project.de/

3 4

[hunchentoot-devel] A couple of issues in Hunchentoot 1.0.0
by Slawek Zak 27 Feb '09

27 Feb '09

Hi list, Thank you very much for your work on Hunchentoot. It's one of my top Lisp tools! After upgrading to 1.0.0 and trying to port and run some of my apps I found several issues, which might use some looking at :) - stream returned by send-headers is binary now. It used to be a flexi stream.It might be worth mentioning in the documentation that it's necessary to wrap it in flexi stream to write character sequences - do-sessions is gone and *session-db* is internal to hunchentoot - *catch-errors-p* is gone and *http-error-handler* is called with HTTP code only (for error page customisation only?). Not-catching lisp errors by hunchentoot was excellent for debugging - calling reset-sessions outside of request context complains about *acceptor* not being set Thanks again, and all the best to you :) Best Regards, /S

2 2

[hunchentoot-devel] *session-secret*
by Leslie P. Polzer 27 Feb '09

27 Feb '09

When the HT user application does not initialize the session secret before starting the first acceptor, a warning is emitted. However neither *session-secret* nor reset-session-secret are exported from the package, so there's no clean way to handle this. I think it should be initialized automatically without any warning (just mention it in the manual) and the symbols should be exported. 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 2

[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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

tbnl-devel February 2009