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

[hunchentoot-devel] Hunchentoot RPM available for Fedora
by Robert Uhl 22 Jun '09

22 Jun '09

I'm pleased to announce the availability of a Hunchentoot RPM for Fedora at <http://yum.octopodial-chrome.com/packages/cl-hunchentoot>. You will almost certainly want to simply install the repo package for octopodial-chrome and then use 'yum install hunchentoot' in order to grab all the pre-reqs. If you have any questions, please feel free to drop me a line. -- Robert Uhl <http://public.xdi.org/=ruhl> Firm footwork is the fount from which springs all offence and defence. --Giacomo diGrasse, 1570

1 0

[hunchentoot-devel] IE https problem
by Edi Weitz 19 Jun '09

19 Jun '09

Sorry if this is a bit off-topic, but I tried to debug this on my own and I also searched Google for quite some time but couldn't find anything yet. I'm now hoping that someone on the list can maybe help with this. I have a Hunchentoot (pre-1.0.0) application running on a customer's server which has been online and running fine for a couple of years now. (It has seen a few updates, but none in the recent months.) The application sits behind an Apache which acts as a proxy in the usual way. Content is served to the client through https which is done by Apache, i.e. Apache talks plain http to Hunchentoot. The application serves, amongst other things, RTF and PDF documents to the clients which are dynamically generated. Some time ago, in the first half of this year, this ceased to work for RTF documents when the client was MSIE 7. This happened after my customer's MSIE 7 browsers received an automatic software update from Microsoft. A bit later the browsers were updated again (to MSIE 8) and now PDF download is also broken. With Firefox, all is still fine. Also, if I access the website through http instead of https, downloads (RTF and PDF) still work fine. Judging from the timing, this is pretty obviously an incompatibility between my app (and/or Hunchentoot) which was introduced due to the MSIE upgrade, but after fighting with this for quite some time I still don't have a clue what the reason is and how I could fix it. The log files don't reveal anything, they just show a normal download of the RTF/PDF document - while MSIE claims that it didn't receive anything. Any ideas/hints? Thanks, Edi.

4 6

[hunchentoot-devel] hunchentoot and sb-ext:run-process experiences
by Cyrus Harmon 11 Jun '09

11 Jun '09

I've finally been motivated to do some maintenance on my web server and one of the things that has been bothering me for a long time has been some relatively serious instability problems with my production- ish hunchentoot server. I had been using a pre-1.0-but-post-last- release development snapshot and the main problem has been that after a week or so of use my hunchentoot instance would fairly reliably crash, although it wasn't clear exactly when it would crash. After I time begin to suspect that the main culprit use my use of sb-ext:run- program in my hunchentoot-cgi stuff. hunchentoot-cgi is a hunchentoot handler and associated glue to allow hunchentoot to call CGI programs written in, say, perl that I wrote primarily so I could put gitweb behind my hunchentoot server directly, instead using apache or lighttpd or whatever as a front-end to hunchentoot. Like most of my code, it is, at least in the beginning, SBCL specific and it uses sb- ext:run-program to launch the CGI script. So far, so good, but then I kept getting these crashes and it was driving me crazy. Today I figured out that if I manually close the process, bad things happen a lot less frequently. This may seem obvious, but if after calling sb-ext:run-program I make an unwind-protect block and call sb- ext:process-wait and sb-ext:process-close, things get a lot better. I guess I should have suspected that something like this might have been the problem when I had errors such as: [2009-06-10 20:37:03 [ERROR]] The value 1026 is not of type (MOD 1025). in the logs, but I never put two and two together. I can now bang on the server (calling CGIs) pretty hard and it generally responds well and hasn't crashed on me yet, although it hasn't been all that long. Nevertheless, a thousand or so hits from ab with the old way of doing things would bring down the server and I can for multiple thousands of hits on the new server with no noticeable problems. I should caveat this by saying that I was seeing the occasional sockout-timeout, writing to a closed pipe, etc... problems with the 1.0 (or thereabouts, whatever is in luis' repo) release, but upgrading to the latest dev version from the ediware svn repo seems to have fixed even those problems. Well, I still occasionally see errors like the following: [2009-06-10 22:35:25 [ERROR]] Couldn't write to #<SB-SYS:FD-STREAM for "a socket" {5A0E5BA1}>: Broken pipe [2009-06-10 22:35:26 [ERROR]] Error while processing connection: Couldn't write to #<SB-SYS:FD-STREAM for "a socket" {5A0E5BA1}>: Broken pipe but they neither bring down the server nor cause ab to freak out with a connection reset by peer error, which is nice. So I guess this all a long-winded way of saying: 1) If you're going to be using sb-ext:run-program :wait nil and reading from the process' stream, make sure you sb-ext:process-close the process. 2) thanks to the hunchentoot team for the 1.0 release and beyond! While I'm at it, I'll put in another plug for my hunchentoot add-on modules, hunchentoot-cgi, hunchentoot-auth and hunchentoot-vhost, for calling CGIs from hunchentoot, for providing (more of) an infrastructure for user authentication, and for trivially handling multiple "virtual hosts" with hunchentoot, respectively: http://git.cyrusharmon.org/cgi-bin/gitweb.cgi?p=hunchentoot-cgi.git http://git.cyrusharmon.org/cgi-bin/gitweb.cgi?p=hunchentoot-auth.git http://git.cyrusharmon.org/cgi-bin/gitweb.cgi?p=hunchentoot-vhost.git All of which should now be working with hunchentoot 1.0 (and beyond). Thanks again to Edi and Hans. Cyrus

2 1

[hunchentoot-devel] cl-who and case-sensitive XML generation
by Patrick May 09 Jun '09

09 Jun '09

I'm trying to generate case-sensitive XML from cl-who. Here's a simple example of what I've tried that doesn't work: (asdf:oos 'asdf:load-op :cl-who) (let ((cl-who::*downcase-tokens-p* nil)) (cl-who:with-html-output-to-string (*standard-output* nil :indent t) (:|Capitalized| (:|CapitalizedCamel| :|camelCase| "foo" "bar")))) This outputs: " <capitalized> <capitalizedcamel camelcase='foo'> bar </capitalizedcamel> </capitalized>" rather than: " <Capitalized> <CapitalizedCamel camelCase='foo'> bar </CapitalizedCamel> </Capitalized>" Can cl-who do what I need? If it can, can it also generate double- quoted strings ("foo" instead of 'foo')? I'm using Clozure and I don't control the XML schema, unfortunately. Thanks, Patrick

4 5

[hunchentoot-devel] A web application framework which uses Hunchentoot
by Tomo Matsumoto 08 Jun '09

08 Jun '09

Hello everyone, This is my first post here. Let me introduce my web application framework which uses Hunchentoot. It's called web4r. http://web4r.org/ Any comment, advice or suggestion will be appreciated. Thanks, Tomo

2 1

[hunchentoot-devel] Multiple websites serving off the same hunchentoot server
by Mackram Raydan 07 Jun '09

07 Jun '09

Hey everyone, I recently started porting several websites I run to sbcl and wish to run them off hunchentoot but would like to run them of the same instance. Is there a way to have hunchentoot serve different directories to different websites? So what I am really asking is can hunchentoot do the following when it recieves a request from www.x.com it would serve pages from my directory /home/me/x and when it recieves a request from www.y.com it would serve pages from my directory /home/me/y Appreciate any help that you could provide and thanks in advance. Regards, Mackram Raydan Website: www.trailoflight.net "An invasion of armies can be resisted, but not an idea whose time has come." Victor Hugo

3 2

[hunchentoot-devel] Error at connection
by Andrei Stebakov 03 Jun '09

03 Jun '09

In the log, I got a lot of messages like: Error: [2009-06-03 14:20:09 [ERROR]] Error while processing connection: couldn't read from #<SB-SYS:FD-STREAM for "a socket" {C8B5159}>: Connection reset by peer Is it something I can eliminate or it's an unavoidable evil of any web server? Thank you, Andrei

1 0

[hunchentoot-devel] Hunchentoot + proxy file uploads
by Tiarnan O'Corrain 02 Jun '09

02 Jun '09

Hi-- wondering if anyone has noticed anything like this: using hunchentoot (verified for versions 0.15 and 1.0.0) with a proxy (verified with nginx and lighttpd), putting a multipart/form-data POST request throught the proxy to the backend hunchentoot process leads to a blank page being delivered with status200. When the hunchentoot process is accessed directly, everything behaves as normal with file uploads. Add the proxy, and everything goes south. Any ideas? Tiarnan -- difficile est saturam non scribere

1 1

[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