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

[hunchentoot-devel] finish-output usage in create-static-file-dispatcher-and-handler
by Volkan YAZICI 16 Apr '07

16 Apr '07

Hi, Just for curiosity, in create-static-file-dispatcher-and-handler function, wouldn't it be better if we flush the buffer finally in the loop instead of calling finish-output at every step. Does it have a special objective, e.g., for debugging purposes, portability issues? And maybe, it'd even be better to use (or to support optionally) force-output instead of finish-output. (With price of not receiving any acknowledgment about the flushed buffer.) Regards.

2 1

[hunchentoot-devel] Unit testing Hunchentoot websites
by Slava Akhmechet 16 Apr '07

16 Apr '07

I'm building a web framework on top of Hunchentoot and I ran into problems while trying to unit test some of my code. Essentially I need to unit test behavior that happens accross requests. I want to do it without starting Hunchentoot by faking the necessary objects (request, session, etc.) The documentation says the usual special variables passed to handlers contain opaque objects. Hunchentoot provides no means of instantiating them manually (unless I get into internal code, which will tie me to the implementation). I see two possible solutions: 1. Abstract my code away from Hunchentoot objects. This way I can fake the necessary environment during unit testing and use Hunchentoot's environment during the real thing. 2. Create my own objects and make sure all appropriate symbols are defined for them - essentially faking Huchentoot's API. It seems like the first option is a better one, but I feel like Huchentoot should provide some support for this. I'd be happy to hack it in if I get some direction (as I'm new to Hunchentoot and CL in general). -- Regards, Slava Akhmechet.

3 7

[hunchentoot-devel] I/O timeout error (SBCL)
by red daly 16 Apr '07

16 Apr '07

This is a repeat of an earlier problem one user had, as documented in this thread: http://common-lisp.net/pipermail/tbnl-devel/2006-December/000876.html >Basically, mx explanation in the other email was right except for the >logging part. There should /probably/ be some cleanup that prevents >errors like this one (that aren't really errors) to pop up the >debugger. Maybe an intrigued soul will contribute a patch. The bug is more of an annoyance than anything. The original email before I noticed it was a repeat report: I have been noticing this IO error since several months ago. When catch-signals is nil, hunchentoot occasionally throws me into the debugger. It signals at seemingly random points during a server's lifetime. I have a backtrace, but I do not know the source of the error. I am running a 64 bit version of SBCL, though I have noticed this on 32 bit SBCL, too. I/O timeout reading #<SB-SYS:FD-STREAM for "a constant string" {10028FCEB1}> [Condition of type SB-SYS:IO-TIMEOUT] Restarts: 0: [TERMINATE-THREAD] Terminate this thread (#<THREAD "hunchentoot-worker-79" {10027721A1}>) Backtrace: 0: ((LAMBDA (SWANK-BACKEND::DEBUGGER-LOOP-FN)) #<FUNCTION (LAMBDA #) {10067D6969}>) 1: (SWANK::DEBUG-IN-EMACS #<SB-SYS:IO-TIMEOUT {1003007811}>) 2: ((LAMBDA (SWANK-BACKEND::HOOK SWANK-BACKEND::FUN)) #<FUNCTION SWANK:SWANK-DEBUGGER-HOOK> #<CLOSURE (LAMBDA #) {1003007C19}>) 3: (SWANK::CALL-WITH-REDIRECTED-IO #<SWANK::CONNECTION {10034586B1}> #<CLOSURE (LAMBDA #) {1003007C39}>) 4: (SWANK::CALL-WITH-CONNECTION #<SWANK::CONNECTION {10034586B1}> #<CLOSURE (LAMBDA #) {1003007C19}>) 5: (INVOKE-DEBUGGER #<SB-SYS:IO-TIMEOUT {1003007811}>) 6: (INVOKE-DEBUGGER #<SB-SYS:IO-TIMEOUT {1003007811}>) 7: (HUNCHENTOOT::MAYBE-INVOKE-DEBUGGER #<SB-SYS:IO-TIMEOUT {1003007811}>) 8: (SIGNAL #<SB-SYS:IO-TIMEOUT {1003007811}>) 9: (ERROR SB-SYS:IO-TIMEOUT) 10: (SB-IMPL::REFILL-BUFFER/FD #<SB-SYS:FD-STREAM for "a constant string" {10028FCEB1}>) 11: (SB-IMPL::INPUT-UNSIGNED-8BIT-BYTE #<SB-SYS:FD-STREAM for "a constant string" {10028FCEB1}> NIL :EOF) 12: ((SB-PCL::FAST-METHOD STREAM-READ-BYTE (CHUNGA:CHUNKED-INPUT-STREAM)) (#(8 9) . #()) #<unavailable argument> #<CHUNGA:CHUNKED-IO-STREAM {1002BE9B91}>) 13: ((SB-PCL::FAST-METHOD FLEXI-STREAMS::READ-BYTE* (FLEXI-STREAMS:FLEXI-INPUT-STREAM)) #<unavailable argument> #<unavailable argument> #<unavailable argument>) 14: ((SB-PCL::FAST-METHOD STREAM-READ-CHAR (FLEXI-STREAMS::FLEXI-LATIN-1-INPUT-STREAM)) #<unavailable argument> #<unavailable argument> #<unavailable argument>) 15: (READ-CHAR #<FLEXI-STREAMS::FLEXI-LATIN-1-IO-STREAM {1002BFEF81}> T NIL #<unused argument>) 16: (CHUNGA:READ-LINE* #<FLEXI-STREAMS::FLEXI-LATIN-1-IO-STREAM {1002BFEF81}> NIL) 17: (HUNCHENTOOT::GET-REQUEST-DATA) 18: (HUNCHENTOOT::PROCESS-CONNECTION #<HUNCHENTOOT::SERVER {10038DFDB1}> #<SB-BSD-SOCKETS:INET-SOCKET descriptor 10 {1002771261}>) 19: ((LAMBDA ())) 20: ("foreign function: #x41EE32") 21: ("foreign function: #x416EF1") -red

2 2

[hunchentoot-devel] Running multiple web application
by Andrei Stebakov 13 Apr '07

13 Apr '07

I just wanted to consult what's the best strategy for using multiple hunchentoot applications. Is it better to use one *dispatch-table* and insert multiple handlers for different application in this table or have many servers listening on different ports? I'd like to go with multiple hunchentoot:start-server, does it have any disadvantages? Thank you, Andrew

6 14

[hunchentoot-devel] *http-error-handler* on IE 7.0 (http code 500)
by Andrei Stebakov 10 Apr '07

10 Apr '07

When I use the *http-error-handler* it works fine on Firefox displaying my message and doing some extra job. On IE it says "Can not display page" and shows the HTTP 500 code. I guess I need to filter out the http status code 500 and replace it for status ok somewhere. How can I replace the status code or fix the page in IE? BTW, when I use (redirect) inside of some of my handlers call I also get to the *http-error-handler*. I guess the proper thing to do is to add +http-moved-temporarily+ into the *approved-return-codes*. Thank you, Andrew

3 5

[hunchentoot-devel] New release 0.8.5
by Edi Weitz 09 Apr '07

09 Apr '07

ChangeLog: Version 0.8.5 2007-04-10 Correct behaviour for "100 Continue" responses Download: http://weitz.de/files/hunchentoot.tar.gz Cheers, Edi.

1 0

[hunchentoot-devel] New release 0.8.4
by Edi Weitz 09 Apr '07

09 Apr '07

No technical changes. This release just fixes some version numbers I botched yesterday. Sorry, Edi.

6 6

[hunchentoot-devel] Processing an error outside the Hunchentoot code
by Andrei Stebakov 08 Apr '07

08 Apr '07

What's the best to add my own error handler? I see there is some processing based on *SHOW-LISP-ERRORS-P* *SHOW-LISP-BACKTRACES-P* inside process-request function, but it doesn't allow to add a user handler of the error (or I just didn't find it). Let's say I don't want a user to see the error (only some nice reassuring message :)) and I want to be notified by an email with the backtrace. Should I go and modify the body of the process-request function (which I'll need to merge with every new release of HT) or is there a way to add my own handler outside of the Hunchentoot code? Thank you, Andrew

3 4

[hunchentoot-devel] New release 0.8.3
by Edi Weitz 07 Apr '07

07 Apr '07

Sorry... ChangeLog: Version 0.8.3 2007-04-07 Don't use chunked encoding for empty (NIL) bodies Download: http://weitz.de/files/hunchentoot.tar.gz Cheers, Edi.

1 0

[hunchentoot-devel] New release 0.8.2
by Edi Weitz 07 Apr '07

07 Apr '07

ChangeLog: Version 0.8.2 2007-04-05 Really exported REASON-PHRASE this time (and also *CURRENT-PROCESS*) Download: http://weitz.de/files/hunchentoot.tar.gz Yes, the date in the ChangeLog is correct, I couldn't upload the code because I couldn't reach my server that day.

1 0