tbnl-devel

tbnl-devel@common-lisp.net

865 discussions

[hunchentoot-devel] Finding out if we're multithreaded
by Vyacheslav Akhmechet 16 Feb '08

16 Feb '08

Hello, Is there an easy way to find out of Hunchentoot is using threads to handle requests? I'd like to issue a warning on single threaded systems, and I'm wondering if there is a unified way to get this information. Thanks, Slava Akhmechet

4 10

[hunchentoot-devel] handle-static-file patch
by Cyrus Harmon 13 Feb '08

13 Feb '08

Currently, if you use create-folder-dispatcher-and-handler to create a handler, it will call handle-static-file on a URL like http://bogushost.tld/this/is/a/directory and will give the contents of the directory as returned by fopen'ing the directory, which probably isn't what we want. The following patch to handle-static-file makes sure that the truename of the file has either a pathname-name or a pathname-type. Not sure if this is desired behavior or not, but I'd rather see a 500 error here. There's another error where if one sets up a folder- dispatcher-and-handler to catch "/www/foo/" and you request "/www/ foo/" you git an internal server error instead of a 500 error, but I haven't worked out the patch for that one yet. Thanks, Cyrus --- misc.lisp Thu Feb 7 18:46:24 2008 +++ misc-patched.lisp Thu Feb 7 18:46:01 2008 @@ -137,11 +137,12 @@ denoted by PATH. Send a content type header corresponding to CONTENT-TYPE or \(if that is NIL) tries to determine the content type via the file's suffix." - (unless (or (pathname-name path) - (pathname-type path)) - ;; not a file - (setf (return-code) +http-bad-request+) - (throw 'handler-done nil)) + (let ((true-path (truename path))) + (unless (or (pathname-name true-path) + (pathname-type true-path)) + ;; not a file + (setf (return-code) +http-bad-request+) + (throw 'handler-done nil))) (unless (probe-file path) ;; does not exist (setf (return-code) +http-not-found+)

3 5

[hunchentoot-devel] parameters
by Rommel Martinez 12 Feb '08

12 Feb '08

Hi! How do I make an HREF link "call" a dispatch function (and "pass" parameters without having to write long strings like this: "/?foo=1&bar=2&baz=3" I am able to do it with forms, using POST, but not with HREFs. :-( Sorry, I'm new to Hunchentoot. Please bear with me. Thanks. :-) -- Rommel M. Martinez <ebzzry(a)gmail.com>

2 2

[hunchentoot-devel] Hunchentoot Thread Safety
by Mostafa Razavi 07 Feb '08

07 Feb '08

Hi. I've been thinking about Hunchentoot's thread safety, lately. I see that for each request Hunchentoot spawns a new thread (if possible, of course) and binds the special variable *request* for it. Initially I thought this could cause problems, but when I did a few tests I found out everything actually seems to work correctly. Now, I'm not complaining why things are not going wrong, only I'm curious how is it that using a dynamic variable, which is one of those dreaded global variables after all, does not cause problems here. You might point out I can find it out all by myself by reading the source code, but unfortunately I couldn't. Maybe I'm missing something. Can anyone here, please, point me to the answer? Thanks. Hom

7 12

[hunchentoot-devel] hunchentoot CGI?
by Cyrus Harmon 01 Feb '08

01 Feb '08

This may seem counterproductive but has anyone used Hunchentoot for running CGI scripts? It seems like this should be pretty straightforward, but I could be missing something. Thanks, Cyrus

2 2

[hunchentoot-devel] Does hunchentoot close the stream returned by SEND-HEADERS?
by Chaitanya Gupta 31 Jan '08

31 Jan '08

Or should it be closed explicitly by the app? Thanks, Chaitanya

2 2

Re: [hunchentoot-devel] Does hunchentoot close the streamreturnedby SEND-HEADERS?
by Cunningham, Jeff 29 Jan '08

29 Jan '08

Edi Weitz wrote: > On Tue, 29 Jan 2008 12:43:54 -0800, "Cunningham, Jeff" <jeffrey.k.cunningham(a)boeing.com> wrote: > > >> I use drakma regularly to examine what is happening on several >> Hunchentoot sites and Hunchentoot always seems to take care of >> closing the streams properly. >> > > Have you ever checked if it also takes care of /not/ closing the > stream if you use Drakma with something like :CLOSE NIL so that you > can re-use the stream? > > Thanks, > Edi. > _______________________________________________ > tbnl-devel site list > tbnl-devel(a)common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > No, I haven't. I'll see if I can give it a try here in the next day. --Jeff

1 0

Re: [hunchentoot-devel] Does hunchentoot close the stream returnedby SEND-HEADERS?
by Cunningham, Jeff 29 Jan '08

29 Jan '08

Edi Weitz wrote: > On Tue, 29 Jan 2008 23:07:46 +0530, Chaitanya Gupta <mail(a)chaitanyagupta.com> wrote: > > >> Or should it be closed explicitly by the app? >> > > Handlers should definitely /not/ close the stream themselves. > Hunchentoot is supposed to do the right thing depending on the headers > sent back and forth between the client and the server - sometimes it > will close the stream, sometimes it won't. You can check with Drakma > (for example) if that really happens, but I think it does. > > Edi. > _______________________________________________ > tbnl-devel site list > tbnl-devel(a)common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > I use drakma regularly to examine what is happening on several Hunchentoot sites and Hunchentoot always seems to take care of closing the streams properly. Jeff

2 1

[hunchentoot-devel] OpenMCL and corrupted multipart/form-data posted binary files
by Peter Eddy 21 Jan '08

21 Jan '08

Hi, I noticed today that binary files uploaded to my web app running in Hunchentoot were being corrupted (though text files look fine.) So I tried the hunchentoot test code and found it had the same problem with binary files. This is on OSX (Leopard), Intel 64 bit. I then tried the same hunchentoot test app on a Linux intel 32 bit platform with SBCL and saw similar corruption. However after updating hunchentoot and flexi-streams and maybe other packages (I just did an asdf-install of hunchentoot to get any new stuff, then removed all existing fasls) the corruption went away. Unfortunately updating packages and removing fasls didn't fix the problem on the Mac. Is this a known problem? On both systems I'm using: hunchentoot-0.15.0 flexi-streams-0.14.0 trivial-gray-streams-2006-09-16 chunga-0.4.1 OpenMCL is the 2007-07-22 release SBCL is version 1.0.13-1 thanks, Peter

2 2

[hunchentoot-devel] Ways to work with case sensitive lisps...
by Gary King 20 Jan '08

20 Jan '08

I was just trying to work with Hunchentoot and Allegro MoDeRn lisp and it's not fun. Sensibly enough, both Chunga and Hunchentoot convert headers and such coming from the web into assoc lists with keywords as keys. However, the keywords are created by upcasing the strings and interning them and in MoDeRn lisp, :HOST does not eq :host and this leaves much of the hander code confused. I'm considering either altering make-keyword or switching the test to be case insensitive but I'm concerned that I may miss places that matter. Is anyone bumping into this? regards, -- Gary Warren King, metabang.com Cell: (413) 559 8738 Fax: (206) 338-4052 gwkkwg on Skype * garethsan on AIM

1 0

← Newer
1
...
41
42
43
44
45
46
47
...
87
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

tbnl-devel