tbnl-devel June 2009

tbnl-devel@common-lisp.net

20 participants
12 discussions

[hunchentoot-devel] Hunchentoot on PORT 80
by Phil Marneweck 18 Sep '09

18 Sep '09

Hi Yesterday I tried to run hunchentoot on port 80 for the first time, but a get a "Permission Denied" error when hunchentoot tries to bind to port 80. Between the #ubuntu and #lisp guys we established that nothing else was running on port 80 and that I was indeed running as root. Everybody agreed that it must be that permissions gets dropped some where along the line. Searching the web regarding dropped permissions got me no where. So I was wondering if anybody else got this configuration to work on port 80 and could share their experience with me please. I have a clean ubuntu server, no apache or anything installed. I have an in init.d script that starts up a screen session which runs swank and start up stuff to load hunchentoot etc ie swank-daemon from clwiki. Regards Phil

6 7

[hunchentoot-devel] Problem with late calls to POST-PARAMETERS
by Peter Seibel 21 Aug '09

21 Aug '09

I ran into a problem converting some of my code to run with Hunchentoot 1.0. This patch fixes it and -- as far as I can tell after a bit of poking around -- is possibly righteous. What do you think? The basic problem that I ran into is explained in the comment in the patch. -Peter diff -r 635083ac9419 hunchentoot/request.lisp --- a/hunchentoot/request.lisp Sun May 31 11:31:25 2009 -0700 +++ b/hunchentoot/request.lisp Mon Jun 01 14:19:19 2009 -0700 @@ -346,7 +346,12 @@ (get-parameters request)) (defmethod post-parameters :before ((request request)) - (maybe-read-post-parameters :request request)) + ;; Force here because if someone calls POST-PARAMETERS they actually + ;; want them, regardless of why the RAW-POST-DATA has been filled + ;; in. (For instance, if SEND-HEADERS has been called, filling in + ;; RAW-POST-DATA, and then subsequent code calls POST-PARAMETERS, + ;; without the :FORCE flag POST-PARAMETERS would return NIL.) + (maybe-read-post-parameters :request request :force t)) (defun post-parameters* (&optional (request *request*)) "Returns an alist of the POST parameters associated with the REQUEST -- Peter Seibel http://www.codersatwork.com/ http://www.gigamonkeys.com/blog/

6 15

[hunchentoot-devel] hunchnetoot-vhost example
by Phil Marneweck 25 Jun '09

25 Jun '09

Hi I know hunchentoot-vhost is a separate package but I was hoping some one here has used it before. Does anybody have an example of how to use hunchentoot-vhost for example: One hunchentoot server running handling /application1/somepage1.html and /application2/somepage2.html /application1/somepage1.html must be mapped to www.somedomain1.com /application2/somepage2.html must be mapped to www.somedomain2.com Any help would be appreciated thank you. Phil

1 0

[hunchentoot-devel] cl-webdav/doc/CVS directory
by Cyrus Harmon 22 Jun '09

22 Jun '09

Edi/Hans, can one of you you remove that from the svn repo? also, since it's been a year, almost, this seems like a good time to bring up my webdav level 2 support patch I sent to the list last year. The biggest negative, that I can see, of the patch is that it requires cxml-stmp. Nevertheless, I think this is a small price to pay for webdav level 2 support and would like to see this in the repo. Thought? thanks, cyrus

2 2

[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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

tbnl-devel June 2009