From edi at agharta.de  Wed Nov  1 03:03:09 2006
From: edi at agharta.de (Edi Weitz)
Date: Tue, 31 Oct 2006 22:03:09 -0500
Subject: [hunchentoot-devel] Re: Huchentoot
In-Reply-To: <1eb864170610311733q871d404g987a8ba7a398cf8e@mail.gmail.com>
	(William Bland's message of "Tue, 31 Oct 2006 17:33:59 -0800")
References: <1eb864170610311733q871d404g987a8ba7a398cf8e@mail.gmail.com>
Message-ID: <u8xiv7tsi.fsf@agharta.de>

Hi Bill,

[Cc to the mailing list.]

On Tue, 31 Oct 2006 17:33:59 -0800, "William Bland" <doctorbill at gmail.com> wrote:

> I'm trying to get Huchentoot installed - it seems like an excellent
> server from everything I've read.  Unfortunately I'm not able to get
> past an ASDF error:
>
> CL-USER> (asdf:oos 'asdf:load-op :huchentoot-test)
> ; loading system definition from
> ; /Users/wjb/.sbcl/systems/huchentoot-test.asd into #<PACKAGE "ASDF0">
> ; registering #<SYSTEM :HUNCHENTOOT-TEST {12E80149}> as HUNCHENTOOT-TEST
>
> component "huchentoot-test" not found
>    [Condition of type ASDF:MISSING-COMPONENT]
>
> Restarts:
>   0: [ABORT-REQUEST] Abort handling SLIME request.
>   1: [ABORT] Exit debugger, returning to top level.
>
> Backtrace:
>   0: (ASDF:FIND-SYSTEM :HUCHENTOOT-TEST T)
>   1: (ASDF:OPERATE ASDF:LOAD-OP :HUCHENTOOT-TEST)
>   2: (SB-INT:SIMPLE-EVAL-IN-LEXENV (ASDF:OOS (QUOTE ASDF:LOAD-OP)
> :HUCHENTOOT-TEST) #<NULL-LEXENV>)
>
> My ASDF setup does work for all the other libraries I have set up
> here (e.g. all the packages that huchentoot depends on).  I
> installed huchentoot simply by unpacking the tarball into
> ~/.sbcl/.site and then making symbolic links for the two .asd files
> from ~/.sbcl/systems
>
> Do you have any idea what might be going wrong?  This is with SBCL
> 0.9.17 on an Intel MacBook.  If there's anything else I can look at
> to help debug this, let me know and I'll do my best.

If that's the real output from your Lisp session, then the solution
probably is to use "Hunchentoot" instead of "Huchentoot."

:)

Cheers,
Edi.


From edi at agharta.de  Thu Nov  2 02:08:50 2006
From: edi at agharta.de (Edi Weitz)
Date: Wed, 01 Nov 2006 21:08:50 -0500
Subject: [hunchentoot-devel] Re: Huchentoot
In-Reply-To: <1eb864170611010917q16c28fc5o455a7541a31e7621@mail.gmail.com>
	(William Bland's message of "Wed, 1 Nov 2006 09:17:18 -0800")
References: <1eb864170610311733q871d404g987a8ba7a398cf8e@mail.gmail.com>
	<u8xiv7tsi.fsf@agharta.de>
	<1eb864170610312034m5ddcec8dx39eff5451a84feb1@mail.gmail.com>
	<1eb864170611010917q16c28fc5o455a7541a31e7621@mail.gmail.com>
Message-ID: <u3b92eh1p.fsf@agharta.de>

Hi Bill!

Thanks.  I have no plans to add that to the code base, but I'm
forwarding your email to the mailing list, so people can find it and
try it out if they want.

Cheers,
Edi.


On Wed, 1 Nov 2006 09:17:18 -0800, "William Bland" <doctorbill at gmail.com> wrote:

> On 10/31/06, William Bland <doctorbill at gmail.com> wrote:
>>
>> Doh!  Thanks Edi, of course that was it - sorry to have bothered you.
>>
>> I still can't get it to compile in my environment (SBCL on a MacBook)
>> because it complains about the lack of threads,   but I'm glad to at
>> least know what I was doing wrong there!
>>
>
> Hi again,
>
> I have Hunchentoot working now, in SBCL, on my MacBook.  The changes I
> had to make to port-sbcl.lisp were:
>
> 32c32
> < #-(and :sb-thread :sb-unicode)
> ---
>> #-sb-unicode
> 34c34,38
> <   (error "This library needs a version of SBCL with Unicode and
> thread support."))
> ---
>>   (error "This library needs a version of SBCL with Unicode support."))
>>
>> #-sb-thread
>> (eval-when (:compile-toplevel :load-toplevel :execute)
>>   (warn "Without thread support, this library is only useful for development."))
> 67,69c71,74
> <   (sb-thread:make-thread (lambda ()
> <                            (apply function args))
> <                          :name name))
> ---
>>   #+sb-thread(sb-thread:make-thread (lambda ()
>> 				      (apply function args))
>> 				    :name name)
>>   #-sb-thread(apply function args))
>
> Of course it's not really useful for a production web server, but it's
> great to be able to run the thing on my laptop for development before
> I deploy to my server.
>
> I've tested all of the demos in hunchentoot-test.  They appear to work
> perfectly in my non-threaded environment.
>
> Cheers,
> Bill.
> -- 
> William Bland: http://www.abstractnonsense.org/
> Lisp documentation: http://www.lispdoc.com/


From tbnl at rojoma.com  Thu Nov  2 18:15:56 2006
From: tbnl at rojoma.com (Robert J. Macomber)
Date: Thu, 02 Nov 2006 11:15:56 -0700
Subject: [hunchentoot-devel] real-remote-addr and proxy chains
Message-ID: <20061102181555.GA12734@oja.no>

The real-remote-addr function currently returns the value of the
x-forwarded-for header if it's set, or remote-addr if it's not.  In
the case of chains of proxies, this gives unexpected results as each
proxy appends the address it's proxying for onto the end of the list.

Since I imagine this function is intended to be used in situations
where Hunchentoot is sitting behind proxies of its own, I've written a
function to split things up to give a particular entry in this chain.
Most of the time, I imagine you'd just want the address added by the
closest proxy but if (for example) you're behind mod_proxy behind
squid, this function can tell you the address of the agent that hit
the squid server.

I'm not actually quite sure what to call this function.  Originally at
my local site I'd called it "real-remote-addr", replacing
Hunchentoot's own function, but the name's not sitting easily with me.
For one thing, it's got a different API since it takes the number of
hops along the proxy chain to look, and for another it returns NIL if
you fall off the end of the chain (I'm not quite sure that's correct,
but it seems to me to fail better than DWIMly returning the last
available address, since values supplied by the user's original
request are useless anyway).  Anyway, here it is, still with the name
real-remote-addr.

(defvar *proxy-count* 0
  "The length of the chain of server-side proxies in front of
Hunchentoot.")

(defun real-remote-addr (&optional (nth *proxy-count*) (request *request*))
  "Returns the address of the NTH host in the chain of proxies
that set the X-Forwarded-For header.  0 is the address of the
last proxy (or the client, if there are no proxies), 1 the
address of the second proxy (or client if there is only one), and
so forth."
  (if (zerop nth)
      (remote-addr request)
      (let* ((proxies (loop with xff = (header-in :x-forwarded-for request)
                            for pos = 0 then (1+ comma)
                            for comma = (position #\, xff :start pos)
                            collect (string-trim " " (subseq xff pos
                            comma))
                            while comma))
             (position (- (length proxies) nth)))
        (if (minusp position)
            nil
            (nth position proxies)))))
-- 
Robert Macomber
tbnl at rojoma.com


From marijnh at gmail.com  Sat Nov  4 20:48:24 2006
From: marijnh at gmail.com (Marijn Haverbeke)
Date: Sat, 4 Nov 2006 21:48:24 +0100
Subject: [hunchentoot-devel] Confusing Hunchentoot behaviour
Message-ID: <befaa7aa0611041248o38e27ce7l601185c4a232289b@mail.gmail.com>

Hello,

I am going to try to report something that looks like a bug, or maybe
multiple bugs, but right now I am so bewildered that I'm not sure it's not
something stupid I am doing...

It all started when I was playing around with a lisp image and a Hunchentoot
server, trying to get the hang of the library. When I added some things to
*dispatch-table*, the server seemed to completely ignore me. (By the way,
this is SBCL 0.9.18 on Linux behind mod_lisp). This was a bit frustrating.
After poking the source for a bit, and making dispatch-request log the table
it was getting, it turns out the server was using a value different from the
current top-level *dispatch-table*. I assumed this was because it bound the
result of calling *meta-dispatcher* to its own *dispatch-table* binding and
apparently never left process-connections. I was about to write an email to
this list about how this might not be the most desirable behaviour, but
decided to test it one more time to make sure I wouldn't make a fool out of
myself. And what do you know, after restarting my lisp process, starting a
new server, and then messing with the *dispatch-table* it suddenly DID take
my changes into account.

'What the hell', was what I thought. But it got even better. Refreshing the
test page a few times showed that sometimes the changed *request-table* was
used, but other times it would use the old one! I was about to dismiss
Hunchentoot as a bug-ridden pile of weidness at this point.

But while I was writing this incoherent complaint I finally got it --
obviously process-request is called once for every THREAD, and since the
server will keep a bunch of (4 on my setup) long-lived listening threads
when communicating with mod_lisp, strange results will occur when each of
these has a different dispatch-table -- the same client will see different
behaviour from the page. I'd say this is not a desirable feature. A good fix
would be to just call *meta-dispatcher* for every call to dispatch-request,
so that you've always got the most recent dispatch-table and the programmer
can fiddle with that variable from the REPL and immediately see the result.
Unless someone goes and writes a really complicated and expensive
meta-dispatcher this shouldn't be a problem. -- As far as I can see no other
parts of the code refer to the dynamic *dispatch-table* var, so losing that
binding shouldn't be a problem.

Let me know what you think.

Marijn Haverbeke
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20061104/abdf80eb/attachment.html>

From marijnh at gmail.com  Sun Nov  5 10:24:10 2006
From: marijnh at gmail.com (Marijn Haverbeke)
Date: Sun, 5 Nov 2006 11:24:10 +0100
Subject: [hunchentoot-devel] Re: Confusing Hunchentoot behaviour
In-Reply-To: <befaa7aa0611041248o38e27ce7l601185c4a232289b@mail.gmail.com>
References: <befaa7aa0611041248o38e27ce7l601185c4a232289b@mail.gmail.com>
Message-ID: <befaa7aa0611050224t295759c7y2b37efd21c449d65@mail.gmail.com>

After experiencing some more problems, it seems my earlier explanation
doesn't quite explain everything (though it is still valid). Some requests
keep returning a completely empty page, and it turns out they do not even
cause process-request to be called (or the loop in process-connection to go
through a new iteration) -- so it might be an apache or mod_lisp problem
with chunked or keep-alive connections. For your reading pleasure, I
included the headers that apache sent me for a normal working request, and
for a failed one...

Here's the working one (just returning a 3-character test page that said
'foo'):

Date
Sun, 05 Nov 2006 09:42:38 GMT
Server
Apache/1.3.34 (Unix)  (Gentoo) mod_lisp/2.42
Content-Length
3
Keep-Alive
timeout=15, max=99
Connection
Keep-Alive, Keep-Alive
Content-Type
text/html; charset=iso-8859-1

And here is the strange one (obtained by refreshing the very same url, note
the lack of content-lenght -- both returned 200 OK):

Date
Sun, 05 Nov 2006 09:42:35 GMT
Server
Apache/1.3.34 (Unix)  (Gentoo) mod_lisp/2.42
Keep-Alive
timeout=15, max=100
Connection
Keep-Alive
Transfer-Encoding
chunked
Content-Type
text/plain

The problem only seems to occur when refreshing after waiting for a bit.
When refreshing multiple times in a row, I always get the test page, but if
I wait a few minutes and then refresh, the first try usually gives the empty
page. Has anyone experienced something like this?

Regards,
Marijn Haverbeke
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20061105/4df26925/attachment.html>

From edi at agharta.de  Sun Nov  5 20:18:42 2006
From: edi at agharta.de (Edi Weitz)
Date: Sun, 05 Nov 2006 21:18:42 +0100
Subject: [hunchentoot-devel] real-remote-addr and proxy chains
In-Reply-To: <20061102181555.GA12734@oja.no> (Robert J. Macomber's message
	of "Thu, 02 Nov 2006 11:15:56 -0700")
References: <20061102181555.GA12734@oja.no>
Message-ID: <uwt69lk9p.fsf@agharta.de>

On Thu, 02 Nov 2006 11:15:56 -0700, "Robert J. Macomber" <tbnl at rojoma.com> wrote:

> The real-remote-addr function currently returns the value of the
> x-forwarded-for header if it's set, or remote-addr if it's not.  In
> the case of chains of proxies, this gives unexpected results as each
> proxy appends the address it's proxying for onto the end of the
> list.
>
> Since I imagine this function is intended to be used in situations
> where Hunchentoot is sitting behind proxies of its own, I've written
> a function to split things up to give a particular entry in this
> chain.  Most of the time, I imagine you'd just want the address
> added by the closest proxy but if (for example) you're behind
> mod_proxy behind squid, this function can tell you the address of
> the agent that hit the squid server.

Hmm, I see the problem, but that actually wasn't the only situation
this was written for.  I also imagined proxies I wouldn't have control
of like those used by, say, AOL customers.  To be honest, I didn't
even know that chained proxies will add to the XFF header instead of
just replacing it.  Is this behaviour specified somewhere?

Anyway, I was thinking that maybe a better API would look like this:

1. If there is no XFF header, return REMOTE-ADDR as it is now.

2. If there is a XFF header, return two values - the second one is a
   list of all IP addresses in the header, the first one is the last
   element of this list.

How about that?

Cheers,
Edi.


From edi at agharta.de  Sun Nov  5 20:32:04 2006
From: edi at agharta.de (Edi Weitz)
Date: Sun, 05 Nov 2006 21:32:04 +0100
Subject: [hunchentoot-devel] New version 0.4.6 (Was: Confusing Hunchentoot
	behaviour)
In-Reply-To: <befaa7aa0611041248o38e27ce7l601185c4a232289b@mail.gmail.com>
	(Marijn Haverbeke's message of "Sat, 4 Nov 2006 21:48:24 +0100")
References: <befaa7aa0611041248o38e27ce7l601185c4a232289b@mail.gmail.com>
Message-ID: <uslgxljnf.fsf@agharta.de>

On Sat, 4 Nov 2006 21:48:24 +0100, "Marijn Haverbeke" <marijnh at gmail.com> wrote:

> A good fix would be to just call *meta-dispatcher* for every call to
> dispatch-request, so that you've always got the most recent
> dispatch-table and the programmer can fiddle with that variable from
> the REPL and immediately see the result.

I've implemented that now in the new version.  *META-DISPATCHER* came
in pretty late in the game, and it wasn't intended to behave like it
did until 0.4.5.  Thanks for the report.

Cheers,
Edi.


From edi at agharta.de  Sun Nov  5 20:34:04 2006
From: edi at agharta.de (Edi Weitz)
Date: Sun, 05 Nov 2006 21:34:04 +0100
Subject: [hunchentoot-devel] Re: Confusing Hunchentoot behaviour
In-Reply-To: <befaa7aa0611050224t295759c7y2b37efd21c449d65@mail.gmail.com>
	(Marijn Haverbeke's message of "Sun, 5 Nov 2006 11:24:10 +0100")
References: <befaa7aa0611041248o38e27ce7l601185c4a232289b@mail.gmail.com>
	<befaa7aa0611050224t295759c7y2b37efd21c449d65@mail.gmail.com>
Message-ID: <uodrlljk3.fsf@agharta.de>

On Sun, 5 Nov 2006 11:24:10 +0100, "Marijn Haverbeke" <marijnh at gmail.com> wrote:

> Some requests keep returning a completely empty page, and it turns
> out they do not even cause process-request to be called (or the loop
> in process-connection to go through a new iteration) -- so it might
> be an apache or mod_lisp problem with chunked or keep-alive
> connections.

I think that's related to what I've described here:

  http://common-lisp.net/pipermail/tbnl-devel/2006-October/000776.html

Unfortunately, I haven't yet found the time to fix it.

Cheers,
Edi.



From tbnl at rojoma.com  Sun Nov  5 20:48:18 2006
From: tbnl at rojoma.com (Robert J. Macomber)
Date: Sun, 05 Nov 2006 13:48:18 -0700
Subject: [hunchentoot-devel] real-remote-addr and proxy chains
In-Reply-To: <uwt69lk9p.fsf@agharta.de>
References: <20061102181555.GA12734@oja.no> <uwt69lk9p.fsf@agharta.de>
Message-ID: <20061105204818.GA14326@oja.no>

On Sun, Nov 05, 2006 at 09:18:42PM +0100, Edi Weitz wrote:
> On Thu, 02 Nov 2006 11:15:56 -0700, "Robert J. Macomber" <tbnl at rojoma.com> wrote:
> Hmm, I see the problem, but that actually wasn't the only situation
> this was written for.  I also imagined proxies I wouldn't have control
> of like those used by, say, AOL customers.

> To be honest, I didn't even know that chained proxies will add to
> the XFF header instead of just replacing it.  Is this behaviour
> specified somewhere?

I'm not sure.  I couldn't find a formal specification anywhere, but
proxies (in particular Apache's mod_proxy, which is the one I'm
concerned with) certainly do this, specified or not.  Section 4.2 of
RFC2616 requires multiple fields to be combined by appending new
values onto the end, but I can't see anything that requires a proxy
not to outright replace things.

> Anyway, I was thinking that maybe a better API would look like this:
> 
> 1. If there is no XFF header, return REMOTE-ADDR as it is now.
> 
> 2. If there is a XFF header, return two values - the second one is a
>    list of all IP addresses in the header, the first one is the last
>    element of this list.
> 
> How about that?

Well, if you actually want the XFF header, there's always (header-in
:x-forwarded-for) but this would save some processing.  If you want
the "real remote address", presumably you're thinking of looking past
some known proxy (or chain of known proxies) and want the single
address that came into it.  I'm sure the "last address in the list" is
the common case, though.

That's a roundabout way to say "yes, that sounds about right".

Oh, and on another note, COOKIE-OUT returns a (name . cookie) pair
instead of just the cookie.  Is there a reason for this?  I'm pretty
sure it's just a forgotten call to CDR.
-- 
Robert Macomber
tbnl at rojoma.com


From edi at agharta.de  Sun Nov  5 20:59:24 2006
From: edi at agharta.de (Edi Weitz)
Date: Sun, 05 Nov 2006 21:59:24 +0100
Subject: [hunchentoot-devel] real-remote-addr and proxy chains
In-Reply-To: <20061105204818.GA14326@oja.no> (Robert J. Macomber's message
	of "Sun, 05 Nov 2006 13:48:18 -0700")
References: <20061102181555.GA12734@oja.no> <uwt69lk9p.fsf@agharta.de>
	<20061105204818.GA14326@oja.no>
Message-ID: <uk629lidv.fsf@agharta.de>

On Sun, 05 Nov 2006 13:48:18 -0700, "Robert J. Macomber" <tbnl at rojoma.com> wrote:

> Well, if you actually want the XFF header, there's always (header-in
> :x-forwarded-for) but this would save some processing.  If you want
> the "real remote address", presumably you're thinking of looking
> past some known proxy (or chain of known proxies) and want the
> single address that came into it.  I'm sure the "last address in the
> list" is the common case, though.

Er, if the proxies add to the end of the list (which I didn't take
into account), it'd be better to return the first and not the last
element of the list, right?

> Oh, and on another note, COOKIE-OUT returns a (name . cookie) pair
> instead of just the cookie.  Is there a reason for this?  I'm pretty
> sure it's just a forgotten call to CDR.

Yep, will be fixed.

Thanks,
Edi.


From tbnl at rojoma.com  Sun Nov  5 21:18:50 2006
From: tbnl at rojoma.com (Robert J. Macomber)
Date: Sun, 05 Nov 2006 14:18:50 -0700
Subject: [hunchentoot-devel] real-remote-addr and proxy chains
In-Reply-To: <uk629lidv.fsf@agharta.de>
References: <20061102181555.GA12734@oja.no> <uwt69lk9p.fsf@agharta.de>
	<20061105204818.GA14326@oja.no> <uk629lidv.fsf@agharta.de>
Message-ID: <20061105211850.GB14326@oja.no>

On Sun, Nov 05, 2006 at 09:59:24PM +0100, Edi Weitz wrote:
> Er, if the proxies add to the end of the list (which I didn't take
> into account), it'd be better to return the first and not the last
> element of the list, right?

Depends on whether you're interested in the user's (claimed) real
address, or the address the user presents to the web server to which
he thinks he's speaking.  In my case, I'm interested in the latter
(that is, I'm just interested in what REMOTE-ADDR would be if
Hunchentoot weren't behind a server-side proxy).  Having looked at the
documentation for sessions in the past five minutes, I see that that
machinery is interested in the former.
-- 
Robert Macomber
tbnl at rojoma.com


From tobia.conforto at linux.it  Sun Nov  5 22:20:06 2006
From: tobia.conforto at linux.it (Toby)
Date: Sun, 5 Nov 2006 23:20:06 +0100
Subject: [hunchentoot-devel] real-remote-addr and proxy chains
In-Reply-To: <uk629lidv.fsf@agharta.de>
References: <20061102181555.GA12734@oja.no> <uwt69lk9p.fsf@agharta.de>
	<20061105204818.GA14326@oja.no> <uk629lidv.fsf@agharta.de>
Message-ID: <20061105222005.GH2039@localhost.localdomain>

Edi Weitz wrote:
> Er, if the proxies add to the end of the list (which I didn't take
> into account), it'd be better to return the first and not the last
> element of the list, right?

I've made a few tests with open proxies on the net.

Most, if not all, add to the end of the list, instead of replacing it.

Some don't bother to append/replace the list with the client address 
(I guess they would be called "anonymous") and some even append
127.0.0.1 or other internal addresses at the end, for whatever reason.

In any case, seeing as a X-Forwarded-For header is quite easy to forge,
trusting the first element of the list doesn't make much sense.

I guess the only real use would be getting the n-th to the last item, to
trim away n known (and trusted) proxies and get to the real client
address, as seen by the proxy + lisp image server setup.


Toby


From edi at agharta.de  Sun Nov  5 22:57:39 2006
From: edi at agharta.de (Edi Weitz)
Date: Sun, 05 Nov 2006 23:57:39 +0100
Subject: [hunchentoot-devel] New version 0.4.7 (Was: real-remote-addr and
	proxy chains)
In-Reply-To: <20061105211850.GB14326@oja.no> (Robert J. Macomber's message
	of "Sun, 05 Nov 2006 14:18:50 -0700")
References: <20061102181555.GA12734@oja.no> <uwt69lk9p.fsf@agharta.de>
	<20061105204818.GA14326@oja.no> <uk629lidv.fsf@agharta.de>
	<20061105211850.GB14326@oja.no>
Message-ID: <u1wohjycc.fsf_-_@agharta.de>

On Sun, 05 Nov 2006 14:18:50 -0700, "Robert J. Macomber" <tbnl at rojoma.com> wrote:

> Depends on whether you're interested in the user's (claimed) real
> address, or the address the user presents to the web server to which
> he thinks he's speaking.  In my case, I'm interested in the latter
> (that is, I'm just interested in what REMOTE-ADDR would be if
> Hunchentoot weren't behind a server-side proxy).  Having looked at
> the documentation for sessions in the past five minutes, I see that
> that machinery is interested in the former.

OK, I've implemented the version I described in my previous email.
The new release also fixes the bug in COOKIE-OUT you mentioned.

Thanks,
Edi.


From edi at agharta.de  Mon Nov  6 00:06:36 2006
From: edi at agharta.de (Edi Weitz)
Date: Mon, 06 Nov 2006 01:06:36 +0100
Subject: [hunchentoot-devel] New version 0.4.8 (Was: Problems with file
	uploads and mod_lisp)
In-Reply-To: <u8xizc1sx.fsf@agharta.de> (Edi Weitz's message of "Sun, 29 Oct
	2006 03:07:26 +0100")
References: <u8xizc1sx.fsf@agharta.de>
Message-ID: <uejshh20j.fsf@agharta.de>

On Sun, 29 Oct 2006 03:07:26 +0100, Edi Weitz <edi at agharta.de> wrote:

> I just realized that Hunchentoot in its current form has problems
> with file uploads if it's used behind mod_lisp.

I think I've fixed this in 0.4.8 now.  At least I found something in
START-OUTPUT which was obviously wrong and a result of my porting and
re-factoring Hunchentoot/TBNL too hastily.

Cheers,
Edi.


From edi at agharta.de  Mon Nov  6 00:08:10 2006
From: edi at agharta.de (Edi Weitz)
Date: Mon, 06 Nov 2006 01:08:10 +0100
Subject: [hunchentoot-devel] Re: Confusing Hunchentoot behaviour
In-Reply-To: <befaa7aa0611050224t295759c7y2b37efd21c449d65@mail.gmail.com>
	(Marijn Haverbeke's message of "Sun, 5 Nov 2006 11:24:10 +0100")
References: <befaa7aa0611041248o38e27ce7l601185c4a232289b@mail.gmail.com>
	<befaa7aa0611050224t295759c7y2b37efd21c449d65@mail.gmail.com>
Message-ID: <uac35h1xx.fsf@agharta.de>

On Sun, 5 Nov 2006 11:24:10 +0100, "Marijn Haverbeke" <marijnh at gmail.com> wrote:

> Some requests keep returning a completely empty page, and it turns
> out they do not even cause process-request to be called (or the loop
> in process-connection to go through a new iteration) -- so it might
> be an apache or mod_lisp problem with chunked or keep-alive
> connections.

It'd be nice if you could check whether these problems can be
reproduced with 0.4.8 which I just released.

Thanks,
Edi.


From graham.fawcett at gmail.com  Tue Nov  7 16:30:27 2006
From: graham.fawcett at gmail.com (Graham Fawcett)
Date: Tue, 7 Nov 2006 11:30:27 -0500
Subject: [hunchentoot-devel] New version 0.4.8 (Was: Problems with file
	uploads and mod_lisp)
In-Reply-To: <uejshh20j.fsf@agharta.de>
References: <u8xizc1sx.fsf@agharta.de> <uejshh20j.fsf@agharta.de>
Message-ID: <ae59b7ff0611070830g496d89d2xdcf4044151ef008b@mail.gmail.com>

On 11/5/06, Edi Weitz <edi at agharta.de> wrote:
> On Sun, 29 Oct 2006 03:07:26 +0100, Edi Weitz <edi at agharta.de> wrote:
>
> > I just realized that Hunchentoot in its current form has problems
> > with file uploads if it's used behind mod_lisp.
> I think I've fixed this in 0.4.8 now.  At least I found something in
> START-OUTPUT which was obviously wrong and a result of my porting and
> re-factoring Hunchentoot/TBNL too hastily.

Version 0.4.8 also appears to fix the mod_lisp / keep-alive problem I
reported on Oct 29. Thanks!

Graham


From tbnl at rojoma.com  Tue Nov  7 16:44:51 2006
From: tbnl at rojoma.com (Robert J. Macomber)
Date: Tue, 07 Nov 2006 09:44:51 -0700
Subject: [hunchentoot-devel] Re: New version 0.4.7 (Was: real-remote-addr
	and proxy chains)
In-Reply-To: <u1wohjycc.fsf_-_@agharta.de>
References: <20061102181555.GA12734@oja.no> <uwt69lk9p.fsf@agharta.de>
	<20061105204818.GA14326@oja.no> <uk629lidv.fsf@agharta.de>
	<20061105211850.GB14326@oja.no> <u1wohjycc.fsf_-_@agharta.de>
Message-ID: <20061107164451.GA7054@oja.no>

On Sun, Nov 05, 2006 at 11:57:39PM +0100, Edi Weitz wrote:
> OK, I've implemented the version I described in my previous email.
> The new release also fixes the bug in COOKIE-OUT you mentioned.

Both work beautifully for me.  Thanks!
-- 
Robert Macomber
tbnl at rojoma.com


From tbnl at rojoma.com  Thu Nov  9 21:55:58 2006
From: tbnl at rojoma.com (Robert J. Macomber)
Date: Thu, 09 Nov 2006 14:55:58 -0700
Subject: [hunchentoot-devel] header(s)-out
Message-ID: <20061109215558.GC7054@oja.no>

[oops, originally sent this to tbnl at ... hope that's not a different
list or person.  Hasn't bounced in any case.]

There seems to be some small bugs involving header-out.  The accessor
is documented to take both keywords and strings, but neither works
reliably because:
  The reader will use string-equal if given a string and eq if given a
  symbol, because of the assoc shadowing in the hunchentoot package.
  This will find what it's looking for if it's given a string or if
  it's given a keyword _and_ the header entry was originally created
  with a keyword.

  The writer will do the same, so it's possible to have two different
  entries for any given header in the headers-out list, one for a
  string entry and one for a symbol.  (The code _looks_ like it does
  the right thing, but if "name" is a symbol, it calls the
  symbol-specialized version of assoc which ignores its test
  argument).

Finally, if a header-out entry is created with a symbol, response
generation fails because it uses write-string (or write-line with
mod-lisp) to output the header name, and they don't take string
designators.

Here's a patch which normalizes things so the keys of this alist are
always strings and the lookup is always done with strings.  It uses
string-capitalize to convert keywords when storing in order to make
them have conventional HTTP header capitalization.

--- hunchentoot-0.4.8.orig/reply.lisp	2006-11-05 15:55:06.000000000 -0700
+++ hunchentoot-0.4.8/reply.lisp	2006-11-08 15:40:15.000000000 -0700
@@ -115,7 +115,7 @@
 (defun header-out (name &optional (reply *reply*))
   "Returns the current value of the outgoing http header named NAME.
 NAME should be a keyword or a string."
-  (cdr (assoc name (headers-out reply))))
+  (cdr (assoc (string name) (headers-out reply))))
 
 (defun cookie-out (name &optional (reply *reply*))
   "Returns the current value of the outgoing cookie named
@@ -129,7 +129,8 @@
 created."
   (with-rebinding (name reply)
     (with-unique-names (place)
-      `(let ((,place (assoc ,name (headers-out ,reply) :test #'string-equal)))
+      `(let* ((,name (if (stringp ,name) ,name (string-capitalize ,name)))
+              (,place (assoc ,name (headers-out ,reply))))
          (cond
            (,place
             (setf (cdr ,place) ,new-value))

-- 
Robert Macomber
tbnl at rojoma.com


From edi at agharta.de  Sun Nov 12 13:44:13 2006
From: edi at agharta.de (Edi Weitz)
Date: Sun, 12 Nov 2006 14:44:13 +0100
Subject: [hunchentoot-devel] New release 0.4.9 (Was: header(s)-out)
In-Reply-To: <20061109215558.GC7054@oja.no> (Robert J. Macomber's message of
	"Thu, 09 Nov 2006 14:55:58 -0700")
References: <20061109215558.GC7054@oja.no>
Message-ID: <uejs83hle.fsf@agharta.de>

On Thu, 09 Nov 2006 14:55:58 -0700, "Robert J. Macomber" <tbnl at rojoma.com> wrote:

> There seems to be some small bugs involving header-out.  The
> accessor is documented to take both keywords and strings, but
> neither works reliably because:
>
> [snip]

Yes, you're absolutely right.  Thanks for spotting that.  As I said,
there were obviously too many (untested) changes at once when I
switched from TBNL to Hunchentoot.

> Here's a patch which normalizes things so the keys of this alist are
> always strings and the lookup is always done with strings.

I've changed this a little bit because I prefer that the keys are
strings.

Thanks,
Edi.


From emailmac at gmail.com  Wed Nov 15 02:10:52 2006
From: emailmac at gmail.com (Mac Chan)
Date: Tue, 14 Nov 2006 18:10:52 -0800
Subject: [hunchentoot-devel] hunchentoot file upload performance
Message-ID: <4877ae640611141810i47047e39vcf597eb31725a7f5@mail.gmail.com>

Hi all,

I've been using tbnl behind mod_lisp2 for quite a while.

After Edi merged tbnl with hunchentoot I wanted to get rid of apache
and run hunchentoot in standalone mode for easier deployment (not to
mention the coolness factor of running everything in lisp).

However, I've found that the file upload performance of hunchentoot is
4-10 times slower than tbnl (standalone or behind mod_lisp). I tested
this by uploading a 30mb file in the test upload page.

I'm guessing that Chunga might be the reason, since this is the only
new component introduced.

[ Chunga is currently not optimized towards performance - it is rather
intended to be easy to use and (if possible) to behave correctly.]

On a side note, while the file is being uploaded the cpu will go up to
90-100% (This happens to both tbnl and hunchentoot).

This is not the case when I upload the same file to a php script w/
apache.

Again, my guess is that rfc2388 repeatedly call read-char instead of
grabbing a buffer with read-sequence and decode it as a chunk.

These two issues make migrating to hunchentoot particular painful
because if one of the users uploads a huge file the whole site will
become very unresponsive (in tbnl the cpu spike goes away a lot
faster, but improving the i/o routine is still a big win).


I don't want to blindly guess, but I don't know how to use lispworks'
profiler to profile a multi-threaded server app.

The lispworks profiler requires you to run (profile <forms>) and it
will return the profiling data after running the <form>.

Is there a way to profile hunchentoot without writing individual test
case that simulates uploading a 30 mb file?

What about people using sbcl? How do you go about profiling apps like
hunchentoot?

Thanks.


From edi at agharta.de  Wed Nov 15 06:53:20 2006
From: edi at agharta.de (Edi Weitz)
Date: Wed, 15 Nov 2006 07:53:20 +0100
Subject: [hunchentoot-devel] hunchentoot file upload performance
In-Reply-To: <4877ae640611141810i47047e39vcf597eb31725a7f5@mail.gmail.com> (Mac
	Chan's message of "Tue, 14 Nov 2006 18:10:52 -0800")
References: <4877ae640611141810i47047e39vcf597eb31725a7f5@mail.gmail.com>
Message-ID: <uy7qdkxpb.fsf@agharta.de>

On Tue, 14 Nov 2006 18:10:52 -0800, "Mac Chan" <emailmac at gmail.com> wrote:

> I've been using tbnl behind mod_lisp2 for quite a while.
>
> After Edi merged tbnl with hunchentoot I wanted to get rid of apache
> and run hunchentoot in standalone mode for easier deployment (not to
> mention the coolness factor of running everything in lisp).
>
> However, I've found that the file upload performance of hunchentoot
> is 4-10 times slower than tbnl (standalone or behind mod_lisp). I
> tested this by uploading a 30mb file in the test upload page.

Yes, I've seen the same.

> I'm guessing that Chunga might be the reason, since this is the only
> new component introduced.

That would be my guess as well - Chunga and/or FLEXI-STREAMS.
Including the fact that both Chunga and FLEXI-STREAMS make heavy use
of Gray streams.

> Again, my guess is that rfc2388 repeatedly call read-char instead of
> grabbing a buffer with read-sequence and decode it as a chunk.

That is certainly part of the problem.

The only way out is probably to write our own version of the RFC2388
library - which is one of my long-term plans.

> These two issues make migrating to hunchentoot particular painful
> because if one of the users uploads a huge file the whole site will
> become very unresponsive (in tbnl the cpu spike goes away a lot
> faster, but improving the i/o routine is still a big win).
>
> I don't want to blindly guess, but I don't know how to use
> lispworks' profiler to profile a multi-threaded server app.
>
> The lispworks profiler requires you to run (profile <forms>) and it
> will return the profiling data after running the <form>.
>
> Is there a way to profile hunchentoot without writing individual
> test case that simulates uploading a 30 mb file?

I'd like to know the answer too... :)

I think you better chances to get an answer to this question on the LW
mailing list.

Cheers,
Edi.


From edi at agharta.de  Thu Nov 16 00:30:05 2006
From: edi at agharta.de (Edi Weitz)
Date: Thu, 16 Nov 2006 01:30:05 +0100
Subject: [hunchentoot-devel] hunchentoot file upload performance
In-Reply-To: <4877ae640611141810i47047e39vcf597eb31725a7f5@mail.gmail.com> (Mac
	Chan's message of "Tue, 14 Nov 2006 18:10:52 -0800")
References: <4877ae640611141810i47047e39vcf597eb31725a7f5@mail.gmail.com>
Message-ID: <uk61wi67m.fsf@agharta.de>

On Tue, 14 Nov 2006 18:10:52 -0800, "Mac Chan" <emailmac at gmail.com> wrote:

> I'm guessing that Chunga might be the reason, since this is the only
> new component introduced.

Actually, the more I think about it the more I'm sure that
FLEXI-STREAMS is the culprit.  I also have an idea how to make it
faster, but I'm not sure if I'll find the time to do it in the next
days.

> Again, my guess is that rfc2388 repeatedly call read-char instead of
> grabbing a buffer with read-sequence and decode it as a chunk.

Because of the way the streams are layered now, you probably wouldn't
win much (if anything at all) if you used READ-SEQUENCE instead.

More later,
Edi.


From emailmac at gmail.com  Thu Nov 16 03:04:10 2006
From: emailmac at gmail.com (Mac Chan)
Date: Wed, 15 Nov 2006 19:04:10 -0800
Subject: [hunchentoot-devel] hunchentoot file upload performance
In-Reply-To: <uk61wi67m.fsf@agharta.de>
References: <4877ae640611141810i47047e39vcf597eb31725a7f5@mail.gmail.com>
	<uk61wi67m.fsf@agharta.de>
Message-ID: <4877ae640611151904m5b86d2a0gf5308ca3339dac63@mail.gmail.com>

On 11/15/06, Edi Weitz <edi at agharta.de> wrote:
> Actually, the more I think about it the more I'm sure that
> FLEXI-STREAMS is the culprit.  I also have an idea how to make it
> faster, but I'm not sure if I'll find the time to do it in the next
> days.

No hurry, Edi. As long as we know there's a solution I'm at ease :-)

> > Again, my guess is that rfc2388 repeatedly call read-char instead of
> > grabbing a buffer with read-sequence and decode it as a chunk.
>
> Because of the way the streams are layered now, you probably wouldn't
> win much (if anything at all) if you used READ-SEQUENCE instead.

So I just did some profiling earlier using the tip from

http://thread.gmane.org/gmane.lisp.lispworks.general/5563/focus=5573

and found that most time are spent in tons of calls to read-char.

I then tried something like reading the whole buffer into a string and
use the (parse-mime string) method instead of (parse-mime stream)
(this is not a fix because if you upload 100mb file, it will allocate
a 100mb buffer).

The result is worse... will investigate later. Also I plan do similar
test with allegro-serve and see if it uses 100% cpu performing the
same task.


From edi at agharta.de  Thu Nov 16 07:32:24 2006
From: edi at agharta.de (Edi Weitz)
Date: Thu, 16 Nov 2006 08:32:24 +0100
Subject: [hunchentoot-devel] hunchentoot file upload performance
In-Reply-To: <4877ae640611151904m5b86d2a0gf5308ca3339dac63@mail.gmail.com> (Mac
	Chan's message of "Wed, 15 Nov 2006 19:04:10 -0800")
References: <4877ae640611141810i47047e39vcf597eb31725a7f5@mail.gmail.com>
	<uk61wi67m.fsf@agharta.de>
	<4877ae640611151904m5b86d2a0gf5308ca3339dac63@mail.gmail.com>
Message-ID: <uirhfaltj.fsf@agharta.de>

On Wed, 15 Nov 2006 19:04:10 -0800, "Mac Chan" <emailmac at gmail.com> wrote:

> I then tried something like reading the whole buffer into a string
> and use the (parse-mime string) method instead of (parse-mime
> stream) (this is not a fix because if you upload 100mb file, it will
> allocate a 100mb buffer).

You could divide this in smaller buffers, but then it gets ugly.  See
below.

> The result is worse...

Yes, as I conjectured in my previous email.  The reason is that
FLEXI-STREAMS currently has to read in octet-size steps anyway.

> will investigate later. Also I plan do similar test with
> allegro-serve and see if it uses 100% cpu performing the same task.

I'm pretty sure it doesn't, mainly for two reasons:

1. For chunking and external format switching it uses AllegroCL's
   built-in "simple streams" - you're unlikely to beat that with
   portable Gray stream solutions like Chunga and FLEXI-STREAMS.

2. Lots of AllegroServe's source (to me) look like C code with
   parentheses around it - pre-allocated buffers and all that stuff.
   That's probably good for performance, but it's not the road I want
   to go.

Cheers,
Edi.


From marijnh at gmail.com  Thu Nov 16 22:09:40 2006
From: marijnh at gmail.com (Marijn Haverbeke)
Date: Thu, 16 Nov 2006 23:09:40 +0100
Subject: [hunchentoot-devel] *http-error-handler* behaviour
Message-ID: <befaa7aa0611161409j6c174084t915737efcfbad0b3@mail.gmail.com>

Hi,

The way in which reply bodies are currently made when a non-200 response
code is set seems a little inconvenient. When no *http-error-handler* is
set, a standard body is given, and when a handler is set it is expected to
generate a body. I was creating a system where bad requests can be signalled
with conditions, which contain an error message that should be given to the
user, and which I was going to render by first calling send-headers and then
writing an html-templates template to the resulting stream... but my efforts
were frustrated by the fact that send-headers calls start-output, which
dumbly generates a body when an error code is set, and the
*http-error-handler* is a rather clumsy way to hook into this -- it doesn't
know anything about the context of the error, and communicating to it by
using a dynamic variable is rather ugly. Maybe an extra argument to (setf
return-code) which suppresses the generating of a standard body would be a
nicer way to allow people to customize their error messages. (Or maybe
having an accessors setf form take different arguments from its normal form
is very bad style. -- Another way could be to leave response-code the way it
is, default to not replacing the body in case of non-200 code, and add
another function which sets the response-code and also enables the
body-replacing functionality for that request.)

Regards,
Marijn Haverbeke
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20061116/4545c657/attachment.html>

From edi at agharta.de  Thu Nov 16 22:29:56 2006
From: edi at agharta.de (Edi Weitz)
Date: Thu, 16 Nov 2006 23:29:56 +0100
Subject: [hunchentoot-devel] *http-error-handler* behaviour
In-Reply-To: <befaa7aa0611161409j6c174084t915737efcfbad0b3@mail.gmail.com>
	(Marijn Haverbeke's message of "Thu, 16 Nov 2006 23:09:40 +0100")
References: <befaa7aa0611161409j6c174084t915737efcfbad0b3@mail.gmail.com>
Message-ID: <uac2r6n4r.fsf@agharta.de>

On Thu, 16 Nov 2006 23:09:40 +0100, "Marijn Haverbeke" <marijnh at gmail.com> wrote:

> the *http-error-handler* is a rather clumsy way to hook into this --
> it doesn't know anything about the context of the error, and
> communicating to it by using a dynamic variable is rather ugly

Well, most of the communication within Hunchentoot is via dynamic
variables... :)

How about AUX-REQUEST-VALUE?

Cheers,
Edi.


From tobia.conforto at linux.it  Thu Nov 16 22:34:17 2006
From: tobia.conforto at linux.it (Toby)
Date: Thu, 16 Nov 2006 23:34:17 +0100
Subject: [hunchentoot-devel] Socket timeout issues
Message-ID: <20061116223416.GA2600@localhost.localdomain>

Hi all

I'm having some trouble with connection timeouts.

I'm writing an AJAX application where I need to push values from the
server to the client at random times (it's a chat application.) 

To avoid polling the server every second, I wrote it like this, to
exploit hanging connections:
 - the client opens a connection with XMLHttpRequest 
 - the server doesn't respond (the handler waits on a condition variable),
   keeping the connection hanging
 - when the server has data to send (new lines of chat) it does so, and:
    - the client receives the data, closes the connection and starts over
 - if the connection timeouts (on either end), the client starts over

This method worked beautifully on SBCL + TBNL + mod_lisp2 + Apache2, on
any browser.  It gave me the lowest possible lag (equal to the network
latency) with very little network overhead.

Now on SBCL 0.9.17 + Hunchentoot 0.4.9 I'm having trouble with the Opera
browser (and possibly others: I've only tested it on Opera and Firefox.)

By the way, Firefox doesn't seem to have any connection timeout: I've
seen it receive a response after a (sleep 1800), without any packet sent
by either side in half an hour!

Anyway I've used a sniffer to understand what's going on.  Usually, when
the connection times out client-side, these packets are exchanged:

  C -> S  ACK FIN
( C <- S  ACK     )
  C <- S  ACK FIN
  C -> S  ACK

This way both sides agree that the connection is over.

But on SBCL + Hunchentoot vs. Opera, after 2 minutes the client times out
and I see the following exchange:

  C -> S  ACK FIN
  C <- S  ACK

I can't make sense of it: why does the server acknowledge the FIN packet
but fail to send its own?

As a result the client thinks it's almost over... enough not to accept
any data from the same connection again, but not enough to stop spinning
and fire the XMLHttpRequest callback (which would open a new connection.)

Even worse, the server thinks it's still open, so it will send any new
data on that wire.  But the data won't be accepted by the client, which
will send a RST as soon as it sees stuff coming from a 'dead' connection.


Help!


Toby

PS: All these tests were done with :read-timeout nil
Maybe I should set it to 119 and forget about it :-)


From edi at agharta.de  Fri Nov 17 07:27:18 2006
From: edi at agharta.de (Edi Weitz)
Date: Fri, 17 Nov 2006 08:27:18 +0100
Subject: [hunchentoot-devel] *http-error-handler* behaviour
In-Reply-To: <befaa7aa0611162256h7a19f462o9caa01c7f1696d69@mail.gmail.com>
	(Marijn Haverbeke's message of "Fri, 17 Nov 2006 07:56:02 +0100")
References: <befaa7aa0611161409j6c174084t915737efcfbad0b3@mail.gmail.com>
	<uac2r6n4r.fsf@agharta.de>
	<befaa7aa0611162256h7a19f462o9caa01c7f1696d69@mail.gmail.com>
Message-ID: <uhcwyr0rt.fsf@agharta.de>

On Fri, 17 Nov 2006 07:56:02 +0100, "Marijn Haverbeke" <marijnh at gmail.com> wrote:

[Please use the mailing list.]

> I hadn't seen aux-request-value yet -- that would definitely be
> better than a dynamic variable. But I'm still not crazy about the
> way the *http-error-handler* just kicks in when the headers are
> being sent. All the other stuff in my app neatly fetches an output
> stream, and then writes its body to it, but for non-200 pages the
> library just refuses to let me do this. (Which means I can't use my
> very nice function for filling and writing a template in this case.)
> Seems a bit arbitrary.

It was intended as a simple solution at a time when there was no
customized error handling at all:

  http://common-lisp.net/pipermail/tbnl-devel/2005-March/000197.html

I still think it is OK as far as it is in line with the way "normal"
content is handled in Hunchentoot.  The only real difference I can see
is that you can't write directly to a stream.

Why you can't use your nice function escapes me, though.  You could
capture its output in a string stream, couldn't you?

If you come up with a solution that obviously improves the current
situation, I'd be happy to include your patches.  Bonus points if the
new stuff is compatible with the old code.  And note that a patch
which changes user-visible behaviour should include documentation as
well - I might otherwise reject it.

Cheers,
Edi.


From edi at agharta.de  Fri Nov 17 07:32:23 2006
From: edi at agharta.de (Edi Weitz)
Date: Fri, 17 Nov 2006 08:32:23 +0100
Subject: [hunchentoot-devel] Socket timeout issues
In-Reply-To: <20061116223416.GA2600@localhost.localdomain> (Toby's message
	of "Thu, 16 Nov 2006 23:34:17 +0100")
References: <20061116223416.GA2600@localhost.localdomain>
Message-ID: <ud57mr0jc.fsf@agharta.de>

On Thu, 16 Nov 2006 23:34:17 +0100, Toby <tobia.conforto at linux.it> wrote:

> I'm having some trouble with connection timeouts.
>
> I'm writing an AJAX application where I need to push values from the
> server to the client at random times (it's a chat application.)
>
> To avoid polling the server every second, I wrote it like this, to
> exploit hanging connections:
>  - the client opens a connection with XMLHttpRequest 
>  - the server doesn't respond (the handler waits on a condition variable),
>    keeping the connection hanging
>  - when the server has data to send (new lines of chat) it does so, and:
>     - the client receives the data, closes the connection and starts over
>  - if the connection timeouts (on either end), the client starts over
>
> This method worked beautifully on SBCL + TBNL + mod_lisp2 + Apache2,
> on any browser.  It gave me the lowest possible lag (equal to the
> network latency) with very little network overhead.
>
> Now on SBCL 0.9.17 + Hunchentoot 0.4.9 I'm having trouble with the
> Opera browser (and possibly others: I've only tested it on Opera and
> Firefox.)
>
> By the way, Firefox doesn't seem to have any connection timeout:
> I've seen it receive a response after a (sleep 1800), without any
> packet sent by either side in half an hour!
>
> Anyway I've used a sniffer to understand what's going on.  Usually,
> when the connection times out client-side, these packets are
> exchanged:
>
>   C -> S  ACK FIN
> ( C <- S  ACK     )
>   C <- S  ACK FIN
>   C -> S  ACK
>
> This way both sides agree that the connection is over.
>
> But on SBCL + Hunchentoot vs. Opera, after 2 minutes the client
> times out and I see the following exchange:
>
>   C -> S  ACK FIN
>   C <- S  ACK
>
> I can't make sense of it: why does the server acknowledge the FIN
> packet but fail to send its own?
>
> As a result the client thinks it's almost over... enough not to
> accept any data from the same connection again, but not enough to
> stop spinning and fire the XMLHttpRequest callback (which would open
> a new connection.)
>
> Even worse, the server thinks it's still open, so it will send any
> new data on that wire.  But the data won't be accepted by the
> client, which will send a RST as soon as it sees stuff coming from a
> 'dead' connection.

I'm afraid I can't help you here - it /looks/ like something that
happens on a level below Hunchentoot.  One thing you could test is if
this happens with AllegroCL or LispWorks as well.  (CMUCL is probably
not a good target as it might be too similar to SBCL.)

If it doesn't happen, I'd suggest taken this to the SBCL mailing list.
If it does, feel free to ask here again although I at least still
wouldn't have an answer...

> PS: All these tests were done with :read-timeout nil Maybe I should
> set it to 119 and forget about it :-)

Have you tried (with a short timeout)?  Does it make a difference?


From marijnh at gmail.com  Fri Nov 17 08:35:17 2006
From: marijnh at gmail.com (Marijn Haverbeke)
Date: Fri, 17 Nov 2006 09:35:17 +0100
Subject: [hunchentoot-devel] *http-error-handler* behaviour
In-Reply-To: <uhcwyr0rt.fsf@agharta.de>
References: <befaa7aa0611161409j6c174084t915737efcfbad0b3@mail.gmail.com>
	<uac2r6n4r.fsf@agharta.de>
	<befaa7aa0611162256h7a19f462o9caa01c7f1696d69@mail.gmail.com>
	<uhcwyr0rt.fsf@agharta.de>
Message-ID: <befaa7aa0611170035o43dcaa67s6c9c66c7f396ae63@mail.gmail.com>

>
> [Please use the mailing list.]


Sorry about that, happened by accident.

It was intended as a simple solution at a time when there was no
> customized error handling at all:
>
>   http://common-lisp.net/pipermail/tbnl-devel/2005-March/000197.html
>
> I still think it is OK as far as it is in line with the way "normal"
> content is handled in Hunchentoot.  The only real difference I can see
> is that you can't write directly to a stream.
>
> Why you can't use your nice function escapes me, though.  You could
> capture its output in a string stream, couldn't you?


It currently  created its own output stream by calling send-headers. I could
add some scaffolding to work around this and allow it to output a string,
but it clashes horribly with the structure of my code, and in this case it
feels like it's the library, not the way my code works, which is making
things difficult. (I might be a bit compulsive-obsessive here, I'll admit.)

If you come up with a solution that obviously improves the current
> situation, I'd be happy to include your patches.  Bonus points if the
> new stuff is compatible with the old code.  And note that a patch
> which changes user-visible behaviour should include documentation as
> well - I might otherwise reject it.


The least-intrusive form I can think of now is to add another configuration
special variable, named *handle-error-codes* or something similar (is error
code a good term for non-200 responses at all?). This one defaults to t, but
when it is set to nil then start-output does not interfere with the bodies
of non-200 responses. If this sounds ok to you I'll implement it tomorrow.
What is the preferred way to submit patches to the docs?

Marijn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20061117/6ba165f6/attachment.html>

From edi at agharta.de  Fri Nov 17 11:10:32 2006
From: edi at agharta.de (Edi Weitz)
Date: Fri, 17 Nov 2006 12:10:32 +0100
Subject: [hunchentoot-devel] *http-error-handler* behaviour
In-Reply-To: <befaa7aa0611170035o43dcaa67s6c9c66c7f396ae63@mail.gmail.com>
	(Marijn Haverbeke's message of "Fri, 17 Nov 2006 09:35:17 +0100")
References: <befaa7aa0611161409j6c174084t915737efcfbad0b3@mail.gmail.com>
	<uac2r6n4r.fsf@agharta.de>
	<befaa7aa0611162256h7a19f462o9caa01c7f1696d69@mail.gmail.com>
	<uhcwyr0rt.fsf@agharta.de>
	<befaa7aa0611170035o43dcaa67s6c9c66c7f396ae63@mail.gmail.com>
Message-ID: <uirhe5nx3.fsf@agharta.de>

On Fri, 17 Nov 2006 09:35:17 +0100, "Marijn Haverbeke" <marijnh at gmail.com> wrote:

> The least-intrusive form I can think of now is to add another
> configuration special variable, named *handle-error-codes* or
> something similar (is error code a good term for non-200 responses
> at all?).

Yeah, "error" probably isn't completely right, but I can live with it.

> This one defaults to t, but when it is set to nil then start-output
> does not interfere with the bodies of non-200 responses.

Sounds OK to me.

> If this sounds ok to you I'll implement it tomorrow.  What is the
> preferred way to submit patches to the docs?

diff -u like the rest.

Thanks,
Edi.


From marijnh at gmail.com  Sat Nov 18 07:47:55 2006
From: marijnh at gmail.com (Marijn Haverbeke)
Date: Sat, 18 Nov 2006 08:47:55 +0100
Subject: [hunchentoot-devel] *http-error-handler* behaviour
In-Reply-To: <uirhe5nx3.fsf@agharta.de>
References: <befaa7aa0611161409j6c174084t915737efcfbad0b3@mail.gmail.com>
	<uac2r6n4r.fsf@agharta.de>
	<befaa7aa0611162256h7a19f462o9caa01c7f1696d69@mail.gmail.com>
	<uhcwyr0rt.fsf@agharta.de>
	<befaa7aa0611170035o43dcaa67s6c9c66c7f396ae63@mail.gmail.com>
	<uirhe5nx3.fsf@agharta.de>
Message-ID: <befaa7aa0611172347v59e73226hbe15b37caf9cf2c9@mail.gmail.com>

Attached is the patch, I went with the name *handle-http-errors-p* instead.

Regards,
Marijn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20061118/a15aaf44/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: handle-http-errors-p.patch
Type: application/octet-stream
Size: 5286 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20061118/a15aaf44/attachment.obj>

From tobia.conforto at linux.it  Sat Nov 18 14:02:50 2006
From: tobia.conforto at linux.it (Toby)
Date: Sat, 18 Nov 2006 15:02:50 +0100
Subject: [hunchentoot-devel] Socket timeout issues
In-Reply-To: <ud57mr0jc.fsf@agharta.de>
References: <20061116223416.GA2600@localhost.localdomain>
	<ud57mr0jc.fsf@agharta.de>
Message-ID: <20061118140250.GB2600@localhost.localdomain>

Edi Weitz wrote:
> > PS: All these tests were done with :read-timeout nil
> > Maybe I should set it to 119 and forget about it 
> 
> Have you tried (with a short timeout)?  Does it make a difference?

Actually, when the client timeout happens the worker thread is waiting
on a condition variable, not on a socket read, so :read-timeout doesn't
have anything to do with my problem.

Instead, timing out of my condition variable after less than 2 minutes
and telling the client to start a new request does work, although it's
not an ideal solution (as some browsers could have a shorter timeout.)


> One thing you could test is if this happens with AllegroCL

I just made some tests with Hunchentoot on AllegroCL, AllegroServe on
AllegroCL and even PHP5 on Apache!  To my surprise, they all behave like
Hunchentoot on SBCL!  Apparently what I considered the "right behaviour"
was a quirk in the mod_lisp2 setup I was using before.

I guess I need to dust some socket programming textbook!


Toby


From edi at agharta.de  Sun Nov 19 20:54:10 2006
From: edi at agharta.de (Edi Weitz)
Date: Sun, 19 Nov 2006 21:54:10 +0100
Subject: [hunchentoot-devel] New release 0.4.10 (Was: *http-error-handler*
	behaviour)
In-Reply-To: <befaa7aa0611172347v59e73226hbe15b37caf9cf2c9@mail.gmail.com>
	(Marijn Haverbeke's message of "Sat, 18 Nov 2006 08:47:55 +0100")
References: <befaa7aa0611161409j6c174084t915737efcfbad0b3@mail.gmail.com>
	<uac2r6n4r.fsf@agharta.de>
	<befaa7aa0611162256h7a19f462o9caa01c7f1696d69@mail.gmail.com>
	<uhcwyr0rt.fsf@agharta.de>
	<befaa7aa0611170035o43dcaa67s6c9c66c7f396ae63@mail.gmail.com>
	<uirhe5nx3.fsf@agharta.de>
	<befaa7aa0611172347v59e73226hbe15b37caf9cf2c9@mail.gmail.com>
Message-ID: <uodr3w425.fsf_-_@agharta.de>

On Sat, 18 Nov 2006 08:47:55 +0100, "Marijn Haverbeke" <marijnh at gmail.com> wrote:

> Attached is the patch, I went with the name *handle-http-errors-p*
> instead.

Thanks a lot - it's in the latest release.

Cheers,
Edi.


From luismbo at gmail.com  Sun Nov 19 21:25:26 2006
From: luismbo at gmail.com (=?ISO-8859-1?Q?Lu=EDs_Oliveira?=)
Date: Sun, 19 Nov 2006 21:25:26 +0000
Subject: [hunchentoot-devel] serve-event support for SBCL and CLISP
Message-ID: <391f79580611191325obc1ad00y831ae7e6724bec7c@mail.gmail.com>

Hello,

I've added a new keyword argument :MODE to START-SERVER that can be
one of :THREADED or :SERVE-EVENT and implemented serve-event support
for SBCL and CLISP. This is a preliminary patch. No real-world testing
or documentation yet. It might however already be useful for people
doing development on, e.g., SBCL/OSX.

In CLISP's case, you have to run (hunchentoot:clisp-serve-events) to
for the server(s) to actually run and handle requests. By the way,
should anyone deploy a server using serve-event, make sure to run it
behind a reverse proxy such as Apache's mod_proxy or Pound otherwise a
client with a slow connection will stall all the other clients.

Also, regarding CLISP, it complains about WRITE-SEQUENCEing a sequence
of (unsigned-byte 8) to a flexi-stream with a character element-type.
See the START-OUTPUT function in headers.lisp towards the end. Not
sure if that was the best fix or whether it should be conditionalized
for CLISP.

Comments welcome.

-- 
Lu?s Oliveira
http://student.dei.uc.pt/~lmoliv/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: serve-event.diff
Type: application/octet-stream
Size: 28885 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20061119/54cb1881/attachment.obj>

From edi at agharta.de  Sun Nov 19 23:07:08 2006
From: edi at agharta.de (Edi Weitz)
Date: Mon, 20 Nov 2006 00:07:08 +0100
Subject: [hunchentoot-devel] Re: Missing functions in Hunchentoot 0.4.10?
In-Reply-To: <1163976043.3771.276502765@webmail.messagingengine.com>
	(lisp@spikeisland.com's
	message of "Sun, 19 Nov 2006 22:40:43 +0000")
References: <1163976043.3771.276502765@webmail.messagingengine.com>
Message-ID: <u7ixrjasj.fsf@agharta.de>

Hi Dominic!

Please use the mailing list.

On Sun, 19 Nov 2006 22:40:43 +0000, "lisp" <lisp at spikeisland.com> wrote:

> I've just downloaded the latest Hunchentoot 0.4.10 but noticed that
> there seem to be a couple of functions missing:
>
> The following functions are undefined: HUNCHENTOOT::OCTETS-TO-STRING
> which is referenced by HUNCHENTOOT:URL-DECODE
> HUNCHENTOOT::STRING-TO-OCTETS which is referenced by
> HUNCHENTOOT::COMPUTE-LENGTH and HUNCHENTOOT:URL-ENCODE
>
> As a result of this (or something else) the test samples aren't
> working.

Looks like you're using an old version of FLEXI-STREAMS.  See the note
about library versions here:

  http://weitz.de/hunchentoot/#install

> As an aside, do you know if anyone is looking at whether UCW can be
> run on top of Hunchentoot?

Don't know.  Have you asked on their mailing list?

Cheers,
Edi.


From luismbo at gmail.com  Mon Nov 20 12:38:39 2006
From: luismbo at gmail.com (=?ISO-8859-1?Q?Lu=EDs_Oliveira?=)
Date: Mon, 20 Nov 2006 12:38:39 +0000
Subject: [hunchentoot-devel] serve-event support for SBCL and CLISP
In-Reply-To: <391f79580611191325obc1ad00y831ae7e6724bec7c@mail.gmail.com>
References: <391f79580611191325obc1ad00y831ae7e6724bec7c@mail.gmail.com>
Message-ID: <391f79580611200438j4f9ba237lb8f061955897ed35@mail.gmail.com>

Hello,

I've added a new keyword argument :MODE to START-SERVER that can be
one of :THREADED or :SERVE-EVENT and implemented serve-event support
for SBCL and CLISP. This is a preliminary patch. No real-world testing
or documentation yet. It might however already be useful for people
doing development on, e.g., SBCL/OSX.

In CLISP's case, you have to run (hunchentoot:clisp-serve-events) to
for the server(s) to actually run and handle requests. By the way,
should anyone deploy a server using serve-event, make sure to run it
behind a reverse proxy such as Apache's mod_proxy or Pound otherwise a
client with a slow connection will stall all the other clients.

Also, regarding CLISP, it complains about WRITE-SEQUENCEing a sequence
of (unsigned-byte 8) to a flexi-stream with a character element-type.
See the START-OUTPUT function in headers.lisp towards the end. Not
sure if that was the best fix or whether it should be conditionalized
for CLISP.

Patch URL:
http://common-lisp.net/~loliveira/patches/serve-event.diff

Comments welcome.

--
Lu?s Oliveira
http://student.dei.uc.pt/~lmoliv/

PS -- This is a resend as my previous message got stuck somewhere.
Sorry if it becomes a duplicate.


From edi at agharta.de  Mon Nov 20 21:17:27 2006
From: edi at agharta.de (Edi Weitz)
Date: Mon, 20 Nov 2006 22:17:27 +0100
Subject: [hunchentoot-devel] serve-event support for SBCL and CLISP
In-Reply-To: <391f79580611191325obc1ad00y831ae7e6724bec7c@mail.gmail.com> 
	=?iso-8859-1?q?=28Lu=EDs?= Oliveira's message of "Sun,
	19 Nov 2006 21:25:26 +0000")
References: <391f79580611191325obc1ad00y831ae7e6724bec7c@mail.gmail.com>
Message-ID: <u64d9izrs.fsf@agharta.de>

Hi,

On Sun, 19 Nov 2006 21:25:26 +0000, "Lu?s Oliveira" <luismbo at gmail.com> wrote:

> I've added a new keyword argument :MODE to START-SERVER that can be
> one of :THREADED or :SERVE-EVENT and implemented serve-event support
> for SBCL and CLISP. This is a preliminary patch. No real-world
> testing or documentation yet. It might however already be useful for
> people doing development on, e.g., SBCL/OSX.

Nice.  Don't hesitate to send a patch once you think it's mature
enough.  (A "real" patch should of course also include the necessary
documentation... :)

> Also, regarding CLISP, it complains about WRITE-SEQUENCEing a
> sequence of (unsigned-byte 8) to a flexi-stream with a character
> element-type.  See the START-OUTPUT function in headers.lisp towards
> the end. Not sure if that was the best fix or whether it should be
> conditionalized for CLISP.

Do you have the latest version of FLEXI-STREAMS?  I thought the CLISP
issues were gone, but I don't use CLISP, so I'm not sure.

Cheers,
Edi.


From edi at agharta.de  Mon Nov 20 22:32:50 2006
From: edi at agharta.de (Edi Weitz)
Date: Mon, 20 Nov 2006 23:32:50 +0100
Subject: [hunchentoot-devel] serve-event support for SBCL and CLISP
In-Reply-To: <391f79580611201350u480730e8q60f0a838202cc0c3@mail.gmail.com> 
	=?iso-8859-1?q?=28Lu=EDs?= Oliveira's message of "Mon,
	20 Nov 2006 21:50:16 +0000")
References: <391f79580611191325obc1ad00y831ae7e6724bec7c@mail.gmail.com>
	<u64d9izrs.fsf@agharta.de>
	<391f79580611201350u480730e8q60f0a838202cc0c3@mail.gmail.com>
Message-ID: <uwt5phhpp.fsf@agharta.de>

[Cc to flexi-streams-devel]

On Mon, 20 Nov 2006 21:50:16 +0000, "Lu?s Oliveira" <luismbo at gmail.com> wrote:

> Hmm, are you supposed to be able to write a sequence of octets onto
> a flexi-stream with element-type character? I can't tell from the
> documentation, though it apparently it works on most Lisps but
> CLISP. If so, what exactly is the element-type for?

Several Lisps have "bivalent" streams where you can write octets as
well as characters to the same stream regardless of its element type.
(I'd say that in this case the element type is just some kind of
"hint" provided by the person who sets it.)  If I were to decide,
flexi streams would also be bivalent - FLEXI-STREAMS is flexible
enough to support that (note the superclasses of FLEXI-INPUT-STREAM,
for example), but apparently CLISP isn't.

I'm not sure if anything in the ANSI spec (or in the Gray streams
specification) explicitely forbids bivalent streams.  If that's the
case, at least LispWorks, AllegroCL, and SBCL are non-confirming, but
I like their behaviour.  My personal opinion is that CLISP's Gray
stream implementation is simply suboptimal.


From luismbo at gmail.com  Mon Nov 20 21:50:16 2006
From: luismbo at gmail.com (=?ISO-8859-1?Q?Lu=EDs_Oliveira?=)
Date: Mon, 20 Nov 2006 21:50:16 +0000
Subject: [hunchentoot-devel] serve-event support for SBCL and CLISP
In-Reply-To: <u64d9izrs.fsf@agharta.de>
References: <391f79580611191325obc1ad00y831ae7e6724bec7c@mail.gmail.com>
	<u64d9izrs.fsf@agharta.de>
Message-ID: <391f79580611201350u480730e8q60f0a838202cc0c3@mail.gmail.com>

On 11/20/06, Edi Weitz <edi at agharta.de> wrote:
> Do you have the latest version of FLEXI-STREAMS?  I thought the CLISP
> issues were gone, but I don't use CLISP, so I'm not sure.

Yes I do. Hmm, are you supposed to be able to write a sequence of
octets onto a flexi-stream with element-type character? I can't tell
from the documentation, though it apparently it works on most Lisps
but CLISP. If so, what exactly is the element-type for?

-- 
Lu?s Oliveira
http://student.dei.uc.pt/~lmoliv/


From travis at travislists.com  Tue Nov 21 01:32:43 2006
From: travis at travislists.com (Travis Cross)
Date: Mon, 20 Nov 2006 20:32:43 -0500
Subject: [hunchentoot-devel] Re: Missing functions in Hunchentoot 0.4.10?
In-Reply-To: <u7ixrjasj.fsf@agharta.de>
References: <1163976043.3771.276502765@webmail.messagingengine.com>
	<u7ixrjasj.fsf@agharta.de>
Message-ID: <4562573B.3080908@travislists.com>

Edi Weitz wrote:
> On Sun, 19 Nov 2006 22:40:43 +0000, "lisp" <lisp at spikeisland.com> wrote:
>> As an aside, do you know if anyone is looking at whether UCW can be
>> run on top of Hunchentoot?
> 
> Don't know.  Have you asked on their mailing list?

I remembered seeing this come across their mailing list, actually:

http://common-lisp.net/pipermail/bese-devel/2006-October/002763.html

Jan Rychter on bese-devel wrote:
> So, is anyone working on a hunchentoot backend? Seems like a very
> reasonable idea given the recent explosive development of hunchentoot,
> its portability enhancements and the overall quality of Edi Weitz's
> libraries.

I couldn't agree more :)

Marco Baringer on bese-devel:
> yes, i've thought of the same thing. i'd like to be able to drop the
> httpd backend and replace it with hunchentoot, but i want to make sure
> that it works as well as the httpd on openmcl and sbcl first. in
> particular i want to make sure hunchentoot, like the httpd, provides
> the option on not keeping the entire request/response in memory. if it
> does we lose the ability to handle large files (this, and stream
> encoding issues, was one of the reasons i wrote the httpd backend in
> the first place).

Cheers,

-- Travis



From edi at agharta.de  Tue Nov 21 06:53:52 2006
From: edi at agharta.de (Edi Weitz)
Date: Tue, 21 Nov 2006 07:53:52 +0100
Subject: [hunchentoot-devel] Re: Missing functions in Hunchentoot 0.4.10?
In-Reply-To: <4562573B.3080908@travislists.com> (Travis Cross's message of
	"Mon, 20 Nov 2006 20:32:43 -0500")
References: <1163976043.3771.276502765@webmail.messagingengine.com>
	<u7ixrjasj.fsf@agharta.de> <4562573B.3080908@travislists.com>
Message-ID: <uvel98f3z.fsf@agharta.de>

On Mon, 20 Nov 2006 20:32:43 -0500, Travis Cross <travis at travislists.com> wrote:

> Marco Baringer on bese-devel:
>
>> in particular i want to make sure hunchentoot, like the httpd,
>> provides the option on not keeping the entire request/response in
>> memory.

It does:

  http://weitz.de/hunchentoot/#send-headers

Cheers,
Edi.


From vamlists at gmail.com  Wed Nov 22 23:06:19 2006
From: vamlists at gmail.com (Vamsee Kanakala)
Date: Thu, 23 Nov 2006 04:36:19 +0530
Subject: [hunchentoot-devel] A simple way to handle logins?
Message-ID: <4564D7EB.7040002@gmail.com>

Hi,

Currently I'm using a simple method to handle logins in Hunchentoot -
set the user object when the user logs in, and check for it at the
beginning of a function whichever needs to have the credentials, or
redirect to login page.

However, most of my functions would require the login-check method to be
run before they display the page. I'm guessing there should be a way to
define a handler which takes all the requests, runs login function and
then sends the request to the appropriate handler. Perhaps I should read
the documentation more thoroughly, though I'd appreciate any tips which
would make it easier.

Thanks,
Vamsee.


From graham.fawcett at gmail.com  Thu Nov 23 02:44:45 2006
From: graham.fawcett at gmail.com (Graham Fawcett)
Date: Wed, 22 Nov 2006 21:44:45 -0500
Subject: [hunchentoot-devel] A simple way to handle logins?
In-Reply-To: <4564D7EB.7040002@gmail.com>
References: <4564D7EB.7040002@gmail.com>
Message-ID: <ae59b7ff0611221844k242c2a07i14bdf177b60a5aec@mail.gmail.com>

On 11/22/06, Vamsee Kanakala <vamlists at gmail.com> wrote:
> Hi,
>
> Currently I'm using a simple method to handle logins in Hunchentoot -
> set the user object when the user logs in, and check for it at the
> beginning of a function whichever needs to have the credentials, or
> redirect to login page.
>
> However, most of my functions would require the login-check method to be
> run before they display the page. I'm guessing there should be a way to
> define a handler which takes all the requests, runs login function and
> then sends the request to the appropriate handler. Perhaps I should read
> the documentation more thoroughly, though I'd appreciate any tips which
> would make it easier.

If possible, arrange your dispatchers so that public
(anonymous-access) dispatchers are at the start of the dispatch table,
and restricted dispatchers appear near the end. Then, you can
introduce a "dummy dispatcher" between the two groups, that performs
the login-check and the redirection to your login page if needed.

For example:

(defun ensure-login (request)
  "A dummy dispatcher that prevents non-logged-in users from passing."
  ;; assuming you're using sessions...
  (and (not-logged-in-p (start-session))
       #'(lambda () (redirect "/login"))))

(defun not-logged-in-p (session) ...)

(setq *dispatch-table*
      (list (create-prefix-dispatcher "/public" 'public-handler)
	    (create-prefix-dispatcher "/login" 'login-handler)
	    #'ensure-login
	    (create-prefix-dispatcher "/admin" 'admin-handler)
	    ;; etc.
	    #'default-dispatcher))

The trick is to have ENSURE-LOGIN return NIL if the user is
logged in. You may still want fine-grained access control in some
of your handlers, but this approach handles the general case
nicely.

Graham


From tobia.conforto at linux.it  Thu Nov 23 10:50:10 2006
From: tobia.conforto at linux.it (Toby)
Date: Thu, 23 Nov 2006 11:50:10 +0100
Subject: [hunchentoot-devel] A simple way to handle logins?
In-Reply-To: <4564D7EB.7040002@gmail.com>
References: <4564D7EB.7040002@gmail.com>
Message-ID: <20061123105010.GD1772@localhost.localdomain>

Vamsee Kanakala wrote:
> set the user object when the user logs in, and check for it at the
> beginning of a function
> 
> However, most of my functions would require the login-check method to
> be run before they display the page.

Here's how I do it:

(declaim (special %current-user%))

(defmacro with-current-user (&body body)
 `(let ((%current-user% (session-value current-user)))
    (unless %current-user% (redirect "/login"))
    , at body))

(defun my-protected-page-handler ()
  (with-current-user
    (with-html-output-to-string (*standard-output* nil :prologue t)
      (:html
        ...

I use this pattern a lot: a session value, a related special variable,
and a macro that binds one to the other, taking action if the session
value is not set.

By the way, special variables bound by (let) forms are thread-specific,
at least on SBCL, so all is well.

You might also find this useful:

(defmacro with-session-values (declarations &body body)
  "with-session-values ({session-value | (var session-value)}*) declaration* form*"
  `(let ,(loop for decl in declarations
               if (listp decl)
                 collect `(,(first decl) (session-value (quote ,(second decl))))
               else
                 collect `(,decl (session-value (quote ,decl))))
     , at body))


Toby


From jeffrey at cunningham.net  Thu Nov 23 18:59:24 2006
From: jeffrey at cunningham.net (Jeffrey Cunningham)
Date: Thu, 23 Nov 2006 10:59:24 -0800
Subject: [hunchentoot-devel] Using SSL
Message-ID: <20061123185924.GA19821@achilles.olympus.net>

Hi all;

I'm trying to understand how SSL works with hunchentoot. I set up a CA
for the domain 'achilles.olympus.net' following the openssl
documentation which produced the public key cacert.pem and the private
key private/cakey.pem. 

Then I started up a server as follows:

(hunchentoot:start-server :port 4243 
  :ssl-certificate-file "ca-cert.pem"
  :ssl-privatekey-file "private/ca-key.pem")

When I browse to the url: 

https://achilles.olympus.net:4243/test

It times out with "Done" and a blank page (no html, no text). 

If I start the same server eithout the SSL certificates on port 4242 and browse the page:

http://achilles.olympus.net:4242/test

It works perfectly (produces my test page as I coded it). 

My understanding of SSL is pretty limited. Is there something obvious
I'm doing wrong? The log entry is unilluminating:

[2006-11-23 10:42:17] 192.168.1.13 - "GET /test HTTP/1.1" 200 680 "-" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.13) Gecko
/20060417"

Thanks for any help.

--Jeff



From edi at agharta.de  Thu Nov 23 20:27:31 2006
From: edi at agharta.de (Edi Weitz)
Date: Thu, 23 Nov 2006 21:27:31 +0100
Subject: [hunchentoot-devel] Using SSL
In-Reply-To: <20061123185924.GA19821@achilles.olympus.net> (Jeffrey
	Cunningham's message of "Thu, 23 Nov 2006 10:59:24 -0800")
References: <20061123185924.GA19821@achilles.olympus.net>
Message-ID: <u64d5di30.fsf@agharta.de>

On Thu, 23 Nov 2006 10:59:24 -0800, Jeffrey Cunningham <jeffrey at cunningham.net> wrote:

> I'm trying to understand how SSL works with hunchentoot. I set up a
> CA for the domain 'achilles.olympus.net' following the openssl
> documentation which produced the public key cacert.pem and the
> private key private/cakey.pem.

Is the private key associated with a password?

> Then I started up a server as follows:
>
> (hunchentoot:start-server :port 4243 
>   :ssl-certificate-file "ca-cert.pem"
>   :ssl-privatekey-file "private/ca-key.pem")

Are you sure the files are found?  Did you try with absolute
pathnames?

> When I browse to the url: 
>
> https://achilles.olympus.net:4243/test
>
> It times out with "Done" and a blank page (no html, no text).

Which Lisp implementation are you using?

Cheers,
Edi.


From edi at agharta.de  Thu Nov 23 21:47:59 2006
From: edi at agharta.de (Edi Weitz)
Date: Thu, 23 Nov 2006 22:47:59 +0100
Subject: [hunchentoot-devel] Using SSL
In-Reply-To: <20061123211649.GA21828@achilles.olympus.net> (Jeffrey
	Cunningham's message of "Thu, 23 Nov 2006 13:16:49 -0800")
References: <20061123185924.GA19821@achilles.olympus.net>
	<u64d5di30.fsf@agharta.de>
	<20061123211649.GA21828@achilles.olympus.net>
Message-ID: <uu00p96nk.fsf@agharta.de>

[Please use the mailing list.]

On Thu, 23 Nov 2006 13:16:49 -0800, Jeffrey Cunningham <jeffrey at cunningham.net> wrote:

> On Thu Nov 23, 2006 at 09:27:31PM +0100, Edi Weitz wrote:
>> 
>> Is the private key associated with a password?
>
> No - no password. 
>
>> Are you sure the files are found?  Did you try with absolute
>> pathnames?
>
> I just tried with absolute pathnames with no change.  Then I
> deliberately misspelled the filenames and tried again, this time it
> gave me "Connection reset while page loading" error in Mozilla and
> the log showed this error:
>
> [2006-11-23 13:13:55 [ERROR]] Error while processing connection: SSL initialization error: Can't load RSA private key ~A
>
> So I think its finding the files.
>
>> Which Lisp implementation are you using?
>
> CMUCL 19d

Hmm, I don't think I ever tested SSL with CMUCL.  The code is based on
CL+SSL which is supposed to work with CMUCL, though.  But it's FFI
code, you never know... :)

Do you have a chance to try with another Lisp (SBCL, LispWorks,
AllegroCL) and the same key files?

Sorry, I don't have another idea ATM.

Cheers,
Edi.


From jeffrey at cunningham.net  Fri Nov 24 20:35:54 2006
From: jeffrey at cunningham.net (Jeffrey Cunningham)
Date: Fri, 24 Nov 2006 12:35:54 -0800
Subject: [hunchentoot-devel] How do I run a standalone server on port 80?
Message-ID: <20061124203554.GA1209@apollo.olympus.net>

I've been bothering Edi in a private email thread that really should have been directed to the list (sorry Edi). Here's the thread:


> On Fri, 24 Nov 2006 08:36:33 -0800, Jeffrey Cunningham <jeffrey at cunningham.net> wrote:
>
> > You say something in your comments about SETUID and SETGID on the
> > process to something other than root, but I don't know how to do
> > that other than write a little C-code. Is there another way? If I
> > understand you correctly, the idea would be to launch the server as
> > root, then change the UID and GID for the running process.
>
>   http://weitz.de/hunchentoot/#start-server
>

Yes, those were the comments I was referring to :

"On Unix you can use setuid and setgid to change the UID and GID of
the process directly after the server has been started. (You might
want to do this if you're using a privileged port like 80.) setuid and
setgid can be integers (the actual IDs) or strings (for the user and
group name respectively)."

Forgive me if this is obvious, but I don't understand. In order to
start the server from lisp running as a regular user, I have to
specify a port. If I specify :port 80, it fails with an error message
that the port is priviliged. So, I don't see how I could change setuid
and setgid "after the server has been started". I see that in the UNIX
package there are two functions: 'setuidexec and 'setgidexec. Would it
work to call these *before* starting the server?

I apologize for taking so much of your time.

Regards,
-Jeff

I think maybe I figured it out. I should start the server from lisp
running as root, but using setuid and setgid values for a
non-privileged user. I was looking at your code and it appears you
switch them after the server has started.

One of the things I really like about your server is the ability to
hack the handler code on the fly while the server is
operating. Wouldn't this be a little dangerous if I have to run from
lisp as root?

--Jeff


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20061124/c176492c/attachment.sig>

From edi at agharta.de  Sat Nov 25 01:27:05 2006
From: edi at agharta.de (Edi Weitz)
Date: Sat, 25 Nov 2006 02:27:05 +0100
Subject: [hunchentoot-devel] setuid/setgid
In-Reply-To: <20061124191451.GA16512@achilles.olympus.net> (Jeffrey
	Cunningham's message of "Fri, 24 Nov 2006 11:14:51 -0800")
References: <20061123185924.GA19821@achilles.olympus.net>
	<u64d5di30.fsf@agharta.de>
	<20061123211649.GA21828@achilles.olympus.net>
	<uu00p96nk.fsf@agharta.de>
	<20061123223601.GA23086@achilles.olympus.net>
	<ubqmxi9xk.fsf@agharta.de>
	<20061124163633.GA23365@achilles.olympus.net>
	<uhcwo4ua4.fsf@agharta.de>
	<20061124191451.GA16512@achilles.olympus.net>
Message-ID: <upsbcwc2e.fsf_-_@agharta.de>

On Fri, 24 Nov 2006 11:14:51 -0800, Jeffrey Cunningham <jeffrey at cunningham.net> wrote:

> On Fri Nov 24, 2006 at 06:41:07PM +0100, Edi Weitz wrote:
>> On Fri, 24 Nov 2006 08:36:33 -0800, Jeffrey Cunningham <jeffrey at cunningham.net> wrote:
>> 
>> > You say something in your comments about SETUID and SETGID on the
>> > process to something other than root, but I don't know how to do
>> > that other than write a little C-code. Is there another way? If I
>> > understand you correctly, the idea would be to launch the server
>> > as root, then change the UID and GID for the running process.
>> 
>>   http://weitz.de/hunchentoot/#start-server
>
> Yes, those were the comments I was referring to :
>
> "On Unix you can use setuid and setgid to change the UID and GID of
> the process directly after the server has been started. (You might
> want to do this if you're using a privileged port like 80.) setuid
> and setgid can be integers (the actual IDs) or strings (for the user
> and group name respectively)."
>
> Forgive me if this is obvious, but I don't understand. In order to
> start the server from lisp running as a regular user, I have to
> specify a port. If I specify :port 80, it fails with an error
> message that the port is priviliged. So, I don't see how I could
> change setuid and setgid "after the server has been started". I see
> that in the UNIX package there are two functions: 'setuidexec and
> 'setgidexec. Would it work to call these *before* starting the
> server?

[Please use the mailing list.]

You start the Lisp image as root, load Hunchentoot, then call
START-SERVER with the corresponding setuid/setgid arguments.  That's
basically how Apache and other apps do it as well (or AllegroServe).

Cheers,
Edi.


From edi at agharta.de  Sat Nov 25 01:28:50 2006
From: edi at agharta.de (Edi Weitz)
Date: Sat, 25 Nov 2006 02:28:50 +0100
Subject: [hunchentoot-devel] Re: setuid/setgid
In-Reply-To: <20061124192827.GA24692@achilles.olympus.net> (Jeffrey
	Cunningham's message of "Fri, 24 Nov 2006 11:28:27 -0800")
References: <20061123185924.GA19821@achilles.olympus.net>
	<u64d5di30.fsf@agharta.de>
	<20061123211649.GA21828@achilles.olympus.net>
	<uu00p96nk.fsf@agharta.de>
	<20061123223601.GA23086@achilles.olympus.net>
	<ubqmxi9xk.fsf@agharta.de>
	<20061124163633.GA23365@achilles.olympus.net>
	<uhcwo4ua4.fsf@agharta.de>
	<20061124192827.GA24692@achilles.olympus.net>
Message-ID: <ulkm0wbzh.fsf_-_@agharta.de>

On Fri, 24 Nov 2006 11:28:27 -0800, Jeffrey Cunningham <jeffrey at cunningham.net> wrote:

> I think maybe I figured it out. I should start the server from lisp
> running as root, but using setuid and setgid values for a
> non-privileged user. I was looking at your code and it appears you
> switch them after the server has started.
>
> One of the things I really like about your server is the ability to
> hack the handler code on the fly while the server is
> operating. Wouldn't this be a little dangerous if I have to run from
> lisp as root?

[Please use the mailing list.]

Once you've called START-SERVER with setuid/setgid, you're no longer
root, so to say.


From edi at agharta.de  Sat Nov 25 01:29:54 2006
From: edi at agharta.de (Edi Weitz)
Date: Sat, 25 Nov 2006 02:29:54 +0100
Subject: [hunchentoot-devel] How do I run a standalone server on port 80?
In-Reply-To: <20061124203554.GA1209@apollo.olympus.net> (Jeffrey
	Cunningham's message of "Fri, 24 Nov 2006 12:35:54 -0800")
References: <20061124203554.GA1209@apollo.olympus.net>
Message-ID: <uhcwowbxp.fsf@agharta.de>

On Fri, 24 Nov 2006 12:35:54 -0800, Jeffrey Cunningham <jeffrey at cunningham.net> wrote:

> I've been bothering Edi in a private email thread that really should
> have been directed to the list (sorry Edi).

Oops, I answered the other emails before I saw this one...


From jeffrey at cunningham.net  Sat Nov 25 01:36:27 2006
From: jeffrey at cunningham.net (Jeffrey Cunningham)
Date: Fri, 24 Nov 2006 17:36:27 -0800
Subject: [hunchentoot-devel] How do I run a standalone server on port 80?
In-Reply-To: <uhcwowbxp.fsf@agharta.de>
References: <20061124203554.GA1209@apollo.olympus.net>
	<uhcwowbxp.fsf@agharta.de>
Message-ID: <20061125013627.GA4093@achilles.olympus.net>

On Sat Nov 25, 2006 at 02:29:54AM +0100, Edi Weitz wrote:
> On Fri, 24 Nov 2006 12:35:54 -0800, Jeffrey Cunningham <jeffrey at cunningham.net> wrote:
> 
> > I've been bothering Edi in a private email thread that really should
> > have been directed to the list (sorry Edi).
> 
> Oops, I answered the other emails before I saw this one...

No problem - I deserved it. ;)

--Jeff




From jeffrey at cunningham.net  Sun Nov 26 02:52:54 2006
From: jeffrey at cunningham.net (Jeffrey Cunningham)
Date: Sat, 25 Nov 2006 18:52:54 -0800
Subject: [hunchentoot-devel] Progress with SSL
Message-ID: <20061126025254.GA27726@achilles.olympus.net>

I've made some progress with my stand-alone server using SSL but still
can't quite get it to work. I'm hoping someone will have an new idea.

I finally figured out how to correctly generate the CA files without
passwords. I start the server like this:

(hunchentoot:start-server 
		      :port 4000
		      :ssl-certificate-file "CA3/ca-cert.pem"
		      :ssl-privatekey-file "CA3/private/ca-key.pem")

When I point a browser at the url
https://achilles.olympus.net:4000/test it brings up a dialog box
asking if I want to accept this unrecognized certificate. I say "yes"
and it then times out after about fifteen seconds without producing
any html.

I know it is going through the test html generator because I added a
log-messages statement in it and it writes my message to the log.

And I know the html generator works alright because if I run the same
server without SSL it generates the test page as it should.

Any ideas?

Regards,
--Jeff



From mlist at rogers.com  Sun Nov 26 17:50:39 2006
From: mlist at rogers.com (vedm)
Date: Sun, 26 Nov 2006 12:50:39 -0500
Subject: [hunchentoot-devel] How to enable directory browsing?
Message-ID: <ekck5f$v9t$1@sea.gmane.org>


When I point the browser to a directory, I want to see a list of the
files in that directory - how can I do this with hunchentoot?

-- 
vedm



From edi at agharta.de  Sun Nov 26 21:56:37 2006
From: edi at agharta.de (Edi Weitz)
Date: Sun, 26 Nov 2006 22:56:37 +0100
Subject: [hunchentoot-devel] How to enable directory browsing?
In-Reply-To: <ekck5f$v9t$1@sea.gmane.org> (vedm's message of "Sun, 26 Nov
	2006 12:50:39 -0500")
References: <ekck5f$v9t$1@sea.gmane.org>
Message-ID: <uejrp6fe2.fsf@agharta.de>

On Sun, 26 Nov 2006 12:50:39 -0500, vedm <mlist at rogers.com> wrote:

> When I point the browser to a directory, I want to see a list of the
> files in that directory - how can I do this with hunchentoot?

You'll have to write a handler to do that for you.

Cheers,
Edi.


From ignas.mikalajunas at gmail.com  Sun Nov 26 20:26:26 2006
From: ignas.mikalajunas at gmail.com (Ignas Mikalajunas)
Date: Sun, 26 Nov 2006 22:26:26 +0200
Subject: [hunchentoot-devel] How to enable directory browsing?
In-Reply-To: <ekck5f$v9t$1@sea.gmane.org>
References: <ekck5f$v9t$1@sea.gmane.org>
Message-ID: <cc0c36330611261226p34a6ad58mf1a46e65a4b20735@mail.gmail.com>

On 11/26/06, vedm <mlist at rogers.com> wrote:
>
> When I point the browser to a directory, I want to see a list of the
> files in that directory - how can I do this with hunchentoot?
>
> --
> vedm

(defun get-uploaded-files ()
  (let* ((pathnames nil))
    (cl-fad:walk-directory (get-config-path :upload-path)
                           (lambda (pathname)
                             (push pathname pathnames)))
    pathnames))

To get a list of all the files.

(create-dynamic-directory-dispatcher
           (get-config-path :upload-path)
           "/files/") in the *dispatch-table* to make them downloadable.

Dispatcher defined as:

(defun join-directories (root relative-path)
  (let ((root-directory (pathname-directory root))
        (relative-directory (pathname-directory relative-path)))
    (append root-directory
            (remove-if 'symbolp relative-directory))))

(defun create-dynamic-directory-dispatcher (directory prefix)
  (lambda (request)
    (let ((script-name (tbnl:script-name request))
          (mismatch (mismatch (tbnl:script-name request) prefix
                              :test #'char=)))
      (and mismatch
         (>= mismatch (length prefix))
         (let ((path (make-pathname :directory
                                    (join-directories directory
                                                      (subseq
script-name mismatch))
                                    :name (pathname-name script-name)
                                    :type (pathname-type script-name))))
           (unless (or (cl-fad:directory-pathname-p path)
                       (not (probe-file path)))
             (lambda ()
               (tbnl:handle-static-file path))))))))

depends on cl-fad. The code is not exceptionally beautiful, yet it
should give you enough ideas to do something more reasonable.

Ignas Mikalaj?nas

From edi at agharta.de  Sun Nov 26 22:38:23 2006
From: edi at agharta.de (Edi Weitz)
Date: Sun, 26 Nov 2006 23:38:23 +0100
Subject: [hunchentoot-devel] Progress with SSL
In-Reply-To: <20061126025254.GA27726@achilles.olympus.net> (Jeffrey
	Cunningham's message of "Sat, 25 Nov 2006 18:52:54 -0800")
References: <20061126025254.GA27726@achilles.olympus.net>
Message-ID: <u3b856dgg.fsf@agharta.de>

On Sat, 25 Nov 2006 18:52:54 -0800, Jeffrey Cunningham <jeffrey at cunningham.net> wrote:

> I finally figured out how to correctly generate the CA files without
> passwords.

Aha!

> When I point a browser at the url
> https://achilles.olympus.net:4000/test it brings up a dialog box
> asking if I want to accept this unrecognized certificate. I say
> "yes" and it then times out after about fifteen seconds without
> producing any html.

As I said - I think the best bet at this point is to try with another
Lisp implementation.  It /might/ be some FFI problem with CL+SSL
that's hard to debug.


From phillip.m.jordan at gmail.com  Sun Nov 26 19:36:08 2006
From: phillip.m.jordan at gmail.com (Phillip Jordan)
Date: Sun, 26 Nov 2006 19:36:08 +0000
Subject: [hunchentoot-devel] How to enable directory browsing?
In-Reply-To: <ekck5f$v9t$1@sea.gmane.org>
References: <ekck5f$v9t$1@sea.gmane.org>
Message-ID: <4569ECA8.8080202@gmail.com>

vedm wrote:
> When I point the browser to a directory, I want to see a list of the
> files in that directory - how can I do this with hunchentoot?
> 

Unless someone has already got some code lying around for this and is
willing to share, you'll have to write your own handler function that
maps the URL to a directory, lists all files and directories of that
directory, and writes them out in some HTML format. You'll probably want
that handler to be the last one in the list, in case there is any URL
ambiguity.

~phil


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20061126/6b5b9f02/attachment.sig>

From ndj at hivsa.com  Thu Nov 30 15:53:32 2006
From: ndj at hivsa.com (Nico de Jager)
Date: Thu, 30 Nov 2006 17:53:32 +0200
Subject: [hunchentoot-devel] Expired sessions
Message-ID: <200611301753.32186.ndj@hivsa.com>

Hi

How do I get rid of expired sessions in hunchentoot without deleting valid 
sessions ("reset-sessions" invalidates and destroys all sessions)?

When looking at the sessions returned by "do-sessions", it seems that expired 
sessions are only removed once a user tries to reuse the expired session. But 
what if the user never revisits the site, will his/her expired session remain 
in the session list? (Or remain at least until the next call to 
"reset-sessions", which will also delete active sessions). How do I identify 
expired sessions when traversing the sessions with "do-session", or do I have 
to manually keep track of this?

Thanks.
Nico




From edi at agharta.de  Thu Nov 30 16:06:39 2006
From: edi at agharta.de (Edi Weitz)
Date: Thu, 30 Nov 2006 17:06:39 +0100
Subject: [hunchentoot-devel] Expired sessions
In-Reply-To: <200611301753.32186.ndj@hivsa.com> (Nico de Jager's message of
	"Thu, 30 Nov 2006 17:53:32 +0200")
References: <200611301753.32186.ndj@hivsa.com>
Message-ID: <uvekwnckw.fsf@agharta.de>

On Thu, 30 Nov 2006 17:53:32 +0200, Nico de Jager <ndj at hivsa.com> wrote:

> How do I get rid of expired sessions in hunchentoot without deleting
> valid sessions ("reset-sessions" invalidates and destroys all
> sessions)?
>
> When looking at the sessions returned by "do-sessions", it seems
> that expired sessions are only removed once a user tries to reuse
> the expired session.

Nope.  See below.

> But what if the user never revisits the site, will his/her expired
> session remain in the session list? (Or remain at least until the
> next call to "reset-sessions", which will also delete active
> sessions). How do I identify expired sessions when traversing the
> sessions with "do-session", or do I have to manually keep track of
> this?

Look at *SESSION-GC-FREQUENCY* and SESSION-GC.  Does that help?  I had
plans to export them but somehow haven't done that yet.  Do others
think this would make sense, at least for the first symbol?

Cheers,
Edi.


From ndj at hivsa.com  Thu Nov 30 17:14:21 2006
From: ndj at hivsa.com (Nico de Jager)
Date: Thu, 30 Nov 2006 19:14:21 +0200
Subject: [hunchentoot-devel] Expired sessions
In-Reply-To: <uvekwnckw.fsf@agharta.de>
References: <200611301753.32186.ndj@hivsa.com> <uvekwnckw.fsf@agharta.de>
Message-ID: <200611301914.21294.ndj@hivsa.com>

On Thursday 30 November 2006 18:06, Edi Weitz wrote:
> On Thu, 30 Nov 2006 17:53:32 +0200, Nico de Jager <ndj at hivsa.com> wrote:
> > How do I get rid of expired sessions in hunchentoot without deleting
> > valid sessions ("reset-sessions" invalidates and destroys all
> > sessions)?
> >
> > When looking at the sessions returned by "do-sessions", it seems
> > that expired sessions are only removed once a user tries to reuse
> > the expired session.
>
> Nope.  See below.
Excellent. I could not determine this from the documentation.

>
> > But what if the user never revisits the site, will his/her expired
> > session remain in the session list? (Or remain at least until the
> > next call to "reset-sessions", which will also delete active
> > sessions). How do I identify expired sessions when traversing the
> > sessions with "do-session", or do I have to manually keep track of
> > this?
>
> Look at *SESSION-GC-FREQUENCY* and SESSION-GC.  Does that help?  I had
> plans to export them but somehow haven't done that yet.  Do others
> think this would make sense, at least for the first symbol?
In my case I want to close the session's database connection when the session 
expires and I was worried that this would only happen as described in my 
previous post. Having these symbols will give finer control, though. If 
SESSION-GC is exported then one can also control this per time period. But 
the current behaviour is adequate for my needs.

Thanks a lot for your quick response.
Nico


From edi at agharta.de  Thu Nov 30 17:19:53 2006
From: edi at agharta.de (Edi Weitz)
Date: Thu, 30 Nov 2006 18:19:53 +0100
Subject: [hunchentoot-devel] Expired sessions
In-Reply-To: <200611301914.21294.ndj@hivsa.com> (Nico de Jager's message of
	"Thu, 30 Nov 2006 19:14:21 +0200")
References: <200611301753.32186.ndj@hivsa.com> <uvekwnckw.fsf@agharta.de>
	<200611301914.21294.ndj@hivsa.com>
Message-ID: <umz68lume.fsf@agharta.de>

On Thu, 30 Nov 2006 19:14:21 +0200, Nico de Jager <ndj at hivsa.com> wrote:

> In my case I want to close the session's database connection when
> the session expires and I was worried that this would only happen as
> described in my previous post.

Have you seen this?

  http://weitz.de/hunchentoot/#*session-removal-hook*



From ndj at hivsa.com  Thu Nov 30 17:32:45 2006
From: ndj at hivsa.com (Nico de Jager)
Date: Thu, 30 Nov 2006 19:32:45 +0200
Subject: [hunchentoot-devel] Expired sessions
In-Reply-To: <umz68lume.fsf@agharta.de>
References: <200611301753.32186.ndj@hivsa.com>
	<200611301914.21294.ndj@hivsa.com> <umz68lume.fsf@agharta.de>
Message-ID: <200611301932.45944.ndj@hivsa.com>

On Thursday 30 November 2006 19:19, Edi Weitz wrote:
> On Thu, 30 Nov 2006 19:14:21 +0200, Nico de Jager <ndj at hivsa.com> wrote:
> > In my case I want to close the session's database connection when
> > the session expires and I was worried that this would only happen as
> > described in my previous post.
>
> Have you seen this?
>
>   http://weitz.de/hunchentoot/#*session-removal-hook*
Yes thanks. That is what I use to close the database connections. But I was 
unsure about when expired sessions are actually deleted. During my tests I 
didn't send *session-gc-frequency* (50) requests and it seemed to me like an 
expired session was only deleted when a user tried to reuse the expired 
session or when you called RESET-SESSIONS.

If you don't export *SESSION-GC-FREQUENCY* and/or SESSION-GC, maybe a short 
note about this can be added to your already excellent documentation?