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

[hunchentoot-devel] redirect doesn't honor *rewrite-for-session-urls*
by Richard KLINDA 23 May '09

23 May '09

Hello, even with *rewrite-for-session-urls* set to nil, the redirect function puts the session ID into the URL by calling add-cookie-value-to-url (under some circumstances). Is this a bug, or am I missing something? Thanks, Richard

2 2

[hunchentoot-devel] Socket errors during requests
by Andrei Stebakov 21 May '09

21 May '09

My log is full of messages like: [2009-05-05 19:29:29 [ERROR]] Error while processing connection: I/O timeout reading #<SB-SYS:FD-STREAM for "a socket" {D0CDBA9}> If I trap the error stack it's like this: 0: (SB-DEBUG::MAP-BACKTRACE #<CLOSURE (LAMBDA #) {CFFA47D}>)[:EXTERNAL] 1: (BACKTRACE 536870911 #<SB-IMPL::STRING-OUTPUT-STREAM {CFB5DA1}>) 2: (TRIVIAL-BACKTRACE:PRINT-BACKTRACE-TO-STREAM #<SB-IMPL::STRING-OUTPUT-STREAM {CFB5DA1}>) 3: (TRIVIAL-BACKTRACE:PRINT-BACKTRACE 0)[:EXTERNAL] 4: (MY-API::MY-MESSAGE-LOGGER :ERROR "Error while processing connection: ~A" #<SB-SYS:IO-TIMEOUT {CF67F81}>) 5: ((FLET #:LAMBDA121) #<SB-SYS:IO-TIMEOUT {CF67F81}>) 6: (SIGNAL #<SB-SYS:IO-TIMEOUT {CF67F81}>)[:EXTERNAL] 7: (ERROR SB-SYS:IO-TIMEOUT)[:EXTERNAL] 8: (SB-IMPL::SIGNAL-TIMEOUT SB-SYS:IO-TIMEOUT)[:EXTERNAL] 9: (SB-IMPL::REFILL-INPUT-BUFFER #<SB-SYS:FD-STREAM for "a socket" {C3DEF69}>) 10: (SB-IMPL::INPUT-UNSIGNED-8BIT-BYTE #<SB-SYS:FD-STREAM for "a socket" {C3DEF69}> NIL NIL) 11: (CHUNGA:READ-CHAR* #<SB-SYS:FD-STREAM for "a socket" {C3DEF69}> NIL NIL) 12: (CHUNGA:READ-LINE* #<SB-SYS:FD-STREAM for "a socket" {C3DEF69}> NIL) 13: (HUNCHENTOOT::READ-INITIAL-REQUEST-LINE #<SB-SYS:FD-STREAM for "a socket" {C3DEF69}>) 14: (HUNCHENTOOT::GET-REQUEST-DATA #<SB-SYS:FD-STREAM for "a socket" {C3DEF69}>) 15: ((SB-PCL::FAST-METHOD HUNCHENTOOT:PROCESS-CONNECTION (HUNCHENTOOT:ACCEPTOR T)) #<unavailable argument> #<unavailable argument> #<MY-API::MY-ACCEPTOR (host *, port 3003)> #<USOCKET:STREAM-USOCKET {C3DFF69}>) 16: ((SB-PCL::FAST-METHOD HUNCHENTOOT:PROCESS-CONNECTION :AROUND (HUNCHENTOOT:ACCEPTOR T)) #<unavailable argument> #S(SB-PCL::FAST-METHOD-CALL :FUNCTION #<FUNCTION #> :PV NIL :NEXT-METHOD-CALL NIL :ARG-INFO (2)) #<MY-API::MY-ACCEPTOR (host *, port 3003)> #<USOCKET:STREAM-USOCKET {C3DFF69}>) 17: ((FLET #:WITHOUT-INTERRUPTS-BODY-[BLOCK353]358)) 18: ((FLET SB-THREAD::WITH-MUTEX-THUNK)) 19: ((FLET #:WITHOUT-INTERRUPTS-BODY-[CALL-WITH-MUTEX]267)) 20: (SB-THREAD::CALL-WITH-MUTEX #<CLOSURE (FLET SB-THREAD::WITH-MUTEX-THUNK) {B6D20245}> #S(SB-THREAD:MUTEX :NAME "thread result lock" :%OWNER #<SB-THREAD:THREAD "Hunchentoot worker (client: 127.0.0.1:44453)" RUNNING {C436EA9}> :STATE 1) #<SB-THREAD:THREAD "Hunchentoot worker (client: 127.0.0.1:44453)" RUNNING {C436EA9}> What could be the reason for the errors? Thank you, Andrei

3 9

[hunchentoot-devel] asterisk
by Dmitri Hrapof 21 May '09

21 May '09

And while I'm at it: why, oh why have you added "*" to those methods? To make people recheck their code's compatibility with new Hunchentoot? BTW, I like the idea of easy-handlers very much. I've been making similar macros for quite a while, and I wonder: do you plan to add to CL-WHO some machinery to reuse these "function arguments"? I mean, often (at least for me) web page contains a form with action pointing to the same page, and it's rather boring to write (:input :type "text" :name "arg1" :value arg1) etc. Again, I have some macros for that, but rather unpolished.

3 7

[hunchentoot-devel] *supports-threads-p*
by Dmitri Hrapof 21 May '09

21 May '09

Hello! If I load Hunchentoot 1.0.0 into ClozureCL, CCL says that *supports-threads-p* is undefined, would you like to use bt:*supports-threads-p* instead? The reason, it seems, is that CCL doesn't like symbol-macro *supports-threads-p* being defined in the same file it's being used. If I move it into e.g. compat.lisp, everything is fine. Cheers, Dmitri

3 3

[hunchentoot-devel] Webpage documentation for REDIRECT function
by Jim Prewett 21 May '09

21 May '09

Hello, I was looking at the Hunchentoot webpage documentation for the REDIRECT function and noticed that it lacked information about what the ADD-SESSION-ID keyword argument does. This information is available in the documentation string for the function (which says "Adds a session ID if ADD-SESSION-ID is true."). Whaddya think about adding that to the webpage as well? 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

2 1

[hunchentoot-devel] redirect problems
by Tiarnan O'Corrain 07 May '09

07 May '09

Hi-- I have a login form on the front page of a site that uses (say) /login.html as its 'action'. Login.html just looks at the post parameters, tries to log the user in, and redirects to the front page, which should then display user specific information. However, the front page displays the old login form, and requires a refresh to pick up the new information. Ditto with logout, which shows the user information until the page is refreshed. I'm using hunchentoot:redirect with the URL, and can't figure out why this isn't working. Any ideas? thanks Tiarnan -- difficile est saturam non scribere

2 1