From peter.stiernstrom at blixtvik.se  Fri Jul  3 11:12:06 2009
From: peter.stiernstrom at blixtvik.se (=?ISO-8859-1?Q?Peter_Stiernstr=F6m?=)
Date: Fri, 03 Jul 2009 13:12:06 +0200
Subject: [hunchentoot-devel] Hunchentoot effective DOS-attack
Message-ID: <4A4DE786.90702@blixtvik.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I don't know if this have come up earlier or if it is a known problem.
If so I am sorry for bringing it up again. A quick look through the
archives turned up a non-caught sbcl socket timeout error with the
obvious fix of adding an error translation to the usocket sbcl backend
error map. I expect this to be somewhat similar.

When stressing hunchentoot with a number of connection like so:

for i in $(seq 1 20); do nmap -sT -p 80 <hostname> ;done

Hunchentoot (last 1.0 release) stops responding after not having caught
a SB-BSD-SOCKETS:NOT-CONNECTED-ERROR thus being easily DOSed.

I was hoping that there would be an obvious similar mapping missing but
I don't know my way around hunchentoot to figure out what to map
SB-BSD-SOCKETS:NOT-CONNECTED-ERROR to.

I am seeing this problem on a regular basis and for now it always
prompts a full restart.

I am using usocket 0.4.1 with hunchentoot 1.0.0.

/Peter
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkpN54YACgkQ0brSZD05ZzARvACfe7SP+QJeHyyQg2zVMKaDL7PI
Z8sAn26so+rYt9eviL/x+E0a6XYORbig
=4rny
-----END PGP SIGNATURE-----



From alex.paes at streetdogstudio.com  Fri Jul  3 17:52:36 2009
From: alex.paes at streetdogstudio.com (Alexandre Paes)
Date: Fri, 03 Jul 2009 19:52:36 +0200
Subject: [hunchentoot-devel] Hunchentoot 1.0.0 on Lispworks Professional for
	windows
Message-ID: <20090703195236.mryzunjruso8c0sk@streetdogstudio.com>

Hi everyone,

I've tried searching the list archives but found no solution or even  
indication of what my problem is.

I'm trying to run a small web app locally from Hunchentoot 1.0.0 on  
Lispworks 5.1.2 on Windows XP, i set asdf and installed hunchentoot  
and it loads perfectly but the thing is that once i run test code  
shown in Hunchentoot homepage:

(hunchentoot:start (make-instance 'hunchentoot:acceptor :port 9000))

It simply returns to the repl and when looking at the process browser  
i can see the Hunchentoot process standing there with "Waiting for  
connection" status.

But when i then go to http://localhost:9000 in firefox i simply get a  
blank page. Does anyone have any idea what might be causing this? I  
the windows firewall disabled and added exceptions to the mcaffee  
firewall, and have even disabled mcaffee firewall but the result is  
always the same.

Thanks in advance,

Alexandre Paes




From hans.huebner at gmail.com  Fri Jul  3 19:33:20 2009
From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Fri, 3 Jul 2009 21:33:20 +0200
Subject: [hunchentoot-devel] Hunchentoot 1.0.0 on Lispworks Professional
	for windows
In-Reply-To: <20090703195236.mryzunjruso8c0sk@streetdogstudio.com>
References: <20090703195236.mryzunjruso8c0sk@streetdogstudio.com>
Message-ID: <fd2982320907031233x6cfa4629x8b8204b7e54b501c@mail.gmail.com>

On Fri, Jul 3, 2009 at 19:52, Alexandre
Paes<alex.paes at streetdogstudio.com> wrote:
> But when i then go to http://localhost:9000 in firefox i simply get a
> blank page. Does anyone have any idea what might be causing this? I
> the windows firewall disabled and added exceptions to the mcaffee
> firewall, and have even disabled mcaffee firewall but the result is
> always the same.

Not that the blank page is cool or anything, but did you actually
install any handlers?  You might try loading the :hunchentoot-test
package and then open http://localhost:9000/hunchentoot/test

Let us know if the problem persists.

-Hans



From enaeher at gmail.com  Fri Jul  3 19:20:16 2009
From: enaeher at gmail.com (Eli Naeher)
Date: Fri, 3 Jul 2009 14:20:16 -0500
Subject: [hunchentoot-devel] Hunchentoot 1.0.0 on Lispworks Professional
	for windows
In-Reply-To: <20090703195236.mryzunjruso8c0sk@streetdogstudio.com>
References: <20090703195236.mryzunjruso8c0sk@streetdogstudio.com>
Message-ID: <ddb4e5590907031220y4a542bd2o354cc916f61d4297@mail.gmail.com>

On Fri, Jul 3, 2009 at 12:52 PM, Alexandre
Paes<alex.paes at streetdogstudio.com> wrote:

> But when i then go to http://localhost:9000 in firefox i simply get a
> blank page. Does anyone have any idea what might be causing this? I
> the windows firewall disabled and added exceptions to the mcaffee
> firewall, and have even disabled mcaffee firewall but the result is
> always the same.

When I ran into similar behavior it turned out to be the result of
using a pre-1.0.0 version of Chunga (see
http://common-lisp.net/pipermail/tbnl-devel/2009-March/004655.html).

--Eli



From alex.paes at streetdogstudio.com  Fri Jul  3 19:57:20 2009
From: alex.paes at streetdogstudio.com (Alexandre Paes)
Date: Fri, 03 Jul 2009 21:57:20 +0200
Subject: [hunchentoot-devel] Hunchentoot 1.0.0 on Lispworks	Professional
	for windows
In-Reply-To: <fd2982320907031233x6cfa4629x8b8204b7e54b501c@mail.gmail.com>
References: <20090703195236.mryzunjruso8c0sk@streetdogstudio.com>
	<fd2982320907031233x6cfa4629x8b8204b7e54b501c@mail.gmail.com>
Message-ID: <20090703215720.ngknw33yso04cwkk@streetdogstudio.com>

Quoting Hans H?bner <hans.huebner at gmail.com>:

> Not that the blank page is cool or anything, but did you actually
> install any handlers?  You might try loading the :hunchentoot-test
> package and then open http://localhost:9000/hunchentoot/test
>
> Let us know if the problem persists.
>
> -Hans

Hi Hans, after trying out loading the :hunchentoot-test like you  
suggested, the result is that the test suite hangs after printing ";  
Request home page", i guess this means there should be some problem  
with the connection to localhost? i also tried using 127.0.0.1  
directly but got the exact same result. any more ideas of how i can  
debug the problem?

Thanks,

Alexandre Paes






From hans.huebner at gmail.com  Fri Jul  3 21:08:10 2009
From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Fri, 3 Jul 2009 23:08:10 +0200
Subject: [hunchentoot-devel] Hunchentoot 1.0.0 on Lispworks Professional
	for windows
In-Reply-To: <20090703215720.ngknw33yso04cwkk@streetdogstudio.com>
References: <20090703195236.mryzunjruso8c0sk@streetdogstudio.com> 
	<fd2982320907031233x6cfa4629x8b8204b7e54b501c@mail.gmail.com> 
	<20090703215720.ngknw33yso04cwkk@streetdogstudio.com>
Message-ID: <fd2982320907031408y371d56d5l20f3d13e76adcdd@mail.gmail.com>

Alexandre, did you verify that you have the right versions of the
dependencies, as Eli rightfully suggested?

-Hans

On Fri, Jul 3, 2009 at 21:57, Alexandre
Paes<alex.paes at streetdogstudio.com> wrote:
> Quoting Hans H?bner <hans.huebner at gmail.com>:
>
>> Not that the blank page is cool or anything, but did you actually
>> install any handlers? ?You might try loading the :hunchentoot-test
>> package and then open http://localhost:9000/hunchentoot/test
>>
>> Let us know if the problem persists.
>>
>> -Hans
>
> Hi Hans, after trying out loading the :hunchentoot-test like you
> suggested, the result is that the test suite hangs after printing ";
> Request home page", i guess this means there should be some problem
> with the connection to localhost? i also tried using 127.0.0.1
> directly but got the exact same result. any more ideas of how i can
> debug the problem?
>
> Thanks,
>
> Alexandre Paes
>
>
>
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>



From alex.paes at streetdogstudio.com  Fri Jul  3 21:33:14 2009
From: alex.paes at streetdogstudio.com (Alexandre Paes)
Date: Fri,  3 Jul 2009 22:33:14 +0100
Subject: [hunchentoot-devel] REF: Re: Hunchentoot 1.0.0 on Lispworks Profes
 sional	for windows
Message-ID: <wRmSP20ckHmz.kQ4VR3xk@mail.streetdogstudio.com>

Hi only after replying did i see eli suggestion but although i was usind chunga 0.4.3 after upgrading the error is the same. I noticed however that if i run the testing code from lw ide instead of console + emacs i end um in the debugger with the error:

; Request home page
Error: no status line - probably network error

i'm using drakma 1.0.0, chunga  1.0.0 and flexi-streams 1.0.7.

i am getting frustrated. One whole day trying to get some html served.

thanks,

Alexandre Paes

-- msg. original --
Assunto:	Re: [hunchentoot-devel] Hunchentoot 1.0.0 on Lispworks Professional	for windows
De:	Hans H?bner <hans.huebner at gmail.com>
Data:		03.07.2009 21:08

Alexandre, did you verify that you have the right versions of the
dependencies, as Eli rightfully suggested?

-Hans

On Fri, Jul 3, 2009 at 21:57, Alexandre
Paes<alex.paes at streetdogstudio.com> wrote:
> Quoting Hans H?bner <hans.huebner at gmail.com>:
>
>> Not that the blank page is cool or anything, but did you actually
>> install any handlers?  You might try loading the :hunchentoot-test
>> package and then open http://localhost:9000/hunchentoot/test
>>
>> Let us know if the problem persists.
>>
>> -Hans
>
> Hi Hans, after trying out loading the :hunchentoot-test like you
> suggested, the result is that the test suite hangs after printing ";
> Request home page", i guess this means there should be some problem
> with the connection to localhost? i also tried using 127.0.0.1
> directly but got the exact same result. any more ideas of how i can
> debug the problem?
>
> Thanks,
>
> Alexandre Paes
>
>
>
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>

_______________________________________________
tbnl-devel site list
tbnl-devel at common-lisp.net
http://common-lisp.net/mailman/listinfo/tbnl-devel




From hans.huebner at gmail.com  Fri Jul  3 23:10:06 2009
From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Sat, 4 Jul 2009 01:10:06 +0200
Subject: [hunchentoot-devel] REF: Re: Hunchentoot 1.0.0 on Lispworks
	Profes sional for windows
In-Reply-To: <wRmSP20ckHmz.kQ4VR3xk@mail.streetdogstudio.com>
References: <wRmSP20ckHmz.kQ4VR3xk@mail.streetdogstudio.com>
Message-ID: <fd2982320907031610t33119f7bxd0cae547c6d01255@mail.gmail.com>

Alexandre,

let's see, here is what I did:

- Get Lispworks 5.1 for Windows from lispworks.com, install on my Vista laptop
- svn co http://bknr.net/svn/ediware
- set up asdf:*central-registry*
- (asdf:oos 'asdf:load-op :hunchentoot-test)
- load http://localhost:9000/hunchentoot/test in browser

Everything worked as expected.  The svn version of Hunchentoot and its
dependencies are sufficiently close to the released versions to make
me believe that you're still using an old version of one of the
dependencies.

I'm sorry to hear that you're having a hard time getting Hunchentoot
to run, but I think you can rest assured that this is not because it
does not work.  It is more likely that you need to acquire some more
experience with your Lisp environment.  Please don't give up!

-Hans



From alex.paes at streetdogstudio.com  Fri Jul  3 23:49:03 2009
From: alex.paes at streetdogstudio.com (Alexandre Paes)
Date: Sat,  4 Jul 2009 00:49:03 +0100
Subject: [hunchentoot-devel] REF: Re: REF: Re: Hunchentoot 1.0.0 on Lispwor
 ks Profes sional for windows
Message-ID: <XN1nHKKdNRrn.djJYjqmF@mail.streetdogstudio.com>

Thanks again Hans,

i will try to follow the steps you describe and see where that leads. By the way, lisp is a real passion for me so rest assured i'm not quitting.

thanks,

Alexandre Paes

-- msg. original --
Assunto:	Re: [hunchentoot-devel] REF: Re: Hunchentoot 1.0.0 on Lispworks  Profes sional for windows
De:	Hans H?bner <hans.huebner at gmail.com>
Data:		03.07.2009 23:10

Alexandre,

let's see, here is what I did:

- Get Lispworks 5.1 for Windows from lispworks.com, install on my Vista laptop
- svn co http://bknr.net/svn/ediware
- set up asdf:*central-registry*
- (asdf:oos 'asdf:load-op :hunchentoot-test)
- load http://localhost:9000/hunchentoot/test in browser

Everything worked as expected.  The svn version of Hunchentoot and its
dependencies are sufficiently close to the released versions to make
me believe that you're still using an old version of one of the
dependencies.

I'm sorry to hear that you're having a hard time getting Hunchentoot
to run, but I think you can rest assured that this is not because it
does not work.  It is more likely that you need to acquire some more
experience with your Lisp environment.  Please don't give up!

-Hans




From hans.huebner at gmail.com  Sun Jul  5 21:39:15 2009
From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Sun, 5 Jul 2009 23:39:15 +0200
Subject: [hunchentoot-devel] Hunchentoot effective DOS-attack
In-Reply-To: <4A4DE786.90702@blixtvik.se>
References: <4A4DE786.90702@blixtvik.se>
Message-ID: <fd2982320907051439w6bd92e6bu516a66b2cb02619c@mail.gmail.com>

Peter,

I am not able to reproduce the problem using the nmap command line
that you provided.  I also ran siege against Hunchentoot:

Transactions:                   1205 hits
Availability:                 100.00 %
Elapsed time:                  14.40 secs
Data transferred:               3.03 MB
Response time:                  0.11 secs
Transaction rate:              83.69 trans/sec
Throughput:                     0.21 MB/sec
Concurrency:                    9.30
Successful transactions:        1205
Failed transactions:               0
Longest transaction:            6.29
Shortest transaction:           0.01

Can you reproduce the problem with siege?  What platform are you
running on?  Can you reproduce the problem when the client is on the
same machine as the server?

It'd be interested to learn where the
SB-BSD-SOCKETS:NOT-CONNECTED-ERROR is actually signalled from.  To
debug, you might set *BREAK-ON-SIGNALS* to
'SB-BSD-SOCKETS:NOT-CONNECTED-ERROR and post the backtrace.

-Hans

2009/7/3 Peter Stiernstr?m <peter.stiernstrom at blixtvik.se>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I don't know if this have come up earlier or if it is a known problem.
> If so I am sorry for bringing it up again. A quick look through the
> archives turned up a non-caught sbcl socket timeout error with the
> obvious fix of adding an error translation to the usocket sbcl backend
> error map. I expect this to be somewhat similar.
>
> When stressing hunchentoot with a number of connection like so:
>
> for i in $(seq 1 20); do nmap -sT -p 80 <hostname> ;done
>
> Hunchentoot (last 1.0 release) stops responding after not having caught
> a SB-BSD-SOCKETS:NOT-CONNECTED-ERROR thus being easily DOSed.
>
> I was hoping that there would be an obvious similar mapping missing but
> I don't know my way around hunchentoot to figure out what to map
> SB-BSD-SOCKETS:NOT-CONNECTED-ERROR to.
>
> I am seeing this problem on a regular basis and for now it always
> prompts a full restart.
>
> I am using usocket 0.4.1 with hunchentoot 1.0.0.
>
> /Peter
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkpN54YACgkQ0brSZD05ZzARvACfe7SP+QJeHyyQg2zVMKaDL7PI
> Z8sAn26so+rYt9eviL/x+E0a6XYORbig
> =4rny
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>



From peter.stiernstrom at blixtvik.se  Mon Jul  6 07:22:45 2009
From: peter.stiernstrom at blixtvik.se (=?ISO-8859-1?Q?Peter_Stiernstr=F6m?=)
Date: Mon, 06 Jul 2009 09:22:45 +0200
Subject: [hunchentoot-devel] Hunchentoot effective DOS-attack
In-Reply-To: <fd2982320907051439w6bd92e6bu516a66b2cb02619c@mail.gmail.com>
References: <4A4DE786.90702@blixtvik.se>
	<fd2982320907051439w6bd92e6bu516a66b2cb02619c@mail.gmail.com>
Message-ID: <4A51A645.3000909@blixtvik.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello Hans!

I have confirmed the problem both when running on localhost and with
seperate machines for client and server. Siege does not act the same way
that nmap -sT does. The problem is noticable with nmap because it
performs a connect without sending any additional data from the nmap man
page I extracted this not so flattery nugget:

> Many services on your average Unix system will add a note to 
> syslog, and sometimes a cryptic error message, when Nmap 
> connects and then closes the connection without sending data.
> Truly pathetic services crash when this happens, though that
> is uncommon.

I noticed myself that I was unable to provoke the uncaught exception
when using a lower number of iterations but it always does this for an
iteration count of 20 on my machines. I'm expecting this could vary a
little so maybe you could raise the number of iterations slightly to
provoke one?

I also did as you suggested and set *break-on-signals*. The trace looks
like this:

Socket error in "getpeername": ENOTCONN (Transport endpoint is not
connected)
BREAK was entered because of *BREAK-ON-SIGNALS* (now rebound to NIL).
   [Condition of type SIMPLE-CONDITION]

Restarts:
 0: [CONTINUE] Return from BREAK.
 1: [REASSIGN] Return from BREAK and assign a new value to
*BREAK-ON-SIGNALS*.
 2: [TERMINATE-THREAD] Terminate this thread (#<THREAD "Hunchentoot
listener (*:8000)" RUNNING {AAA8B51}>)

Backtrace:
  0: (BREAK "~A~%BREAK was entered because of *BREAK-ON-SIGNALS* ~\n
                (now rebound to NIL)."
#<SB-BSD-SOCKETS:NOT-CONNECTED-ERROR {AE7FCA9}>)
  1: (SIGNAL #<SB-BSD-SOCKETS:NOT-CONNECTED-ERROR {AE7FCA9}>)[:EXTERNAL]
  2: (ERROR SB-BSD-SOCKETS:NOT-CONNECTED-ERROR)[:EXTERNAL]
  3: (SB-BSD-SOCKETS:SOCKET-ERROR "getpeername")
  4: (SB-BSD-SOCKETS:SOCKET-ERROR "getpeername")[:EXTERNAL]
  5: ((SB-PCL::FAST-METHOD SB-BSD-SOCKETS:SOCKET-PEERNAME
(SB-BSD-SOCKETS:SOCKET)) #<unavailable argument> #<unavailable argument>
#<SB-BSD-SOCKETS:INET-SOCKET descriptor 6 {AE7F971}>)
  6: ((SB-PCL::FAST-METHOD USOCKET:GET-PEER-ADDRESS
(USOCKET:STREAM-USOCKET)) #<unavailable argument> #<unavailable
argument> #<USOCKET:STREAM-USOCKET {AE7FBD1}>)
  7: (HUNCHENTOOT::CLIENT-AS-STRING #<USOCKET:STREAM-USOCKET {AE7FBD1}>)
  8: ((SB-PCL::FAST-METHOD HUNCHENTOOT:HANDLE-INCOMING-CONNECTION
(HUNCHENTOOT:ONE-THREAD-PER-CONNECTION-TASKMASTER T)) ..)
  9: ((SB-PCL::FAST-METHOD HUNCHENTOOT:ACCEPT-CONNECTIONS
(HUNCHENTOOT:ACCEPTOR)) #<unavailable argument> #<unavailable argument>
#<HUNCHENTOOT:ACCEPTOR (host *, port 8000)>)
 10: ((FLET SB-THREAD::WITH-MUTEX-THUNK))
 11: ((FLET #:WITHOUT-INTERRUPTS-BODY-[CALL-WITH-MUTEX]477))
 12: (SB-THREAD::CALL-WITH-MUTEX ..)
 13: ((LAMBDA ()))
 14: ("foreign function: #x806480C")
 15: ("foreign function: #x8052C21")
 16: ("foreign function: #x805BD9D")
 17: ("foreign function: #xB7FB84C0")

I had a quick peek at client-as-string and it does indeed not handle the
sb-bsd-sockets:not-connected-error and if I put a handler-case around
body of client-as-string returning nil when the exception appears I can
not reproduce my problem anymore.

This wouldn't provide a portable solution though :-P

/Peter

Hans H?bner wrote:
> Peter,
> 
> I am not able to reproduce the problem using the nmap command line
> that you provided.  I also ran siege against Hunchentoot:
> 
> Transactions:                   1205 hits
> Availability:                 100.00 %
> Elapsed time:                  14.40 secs
> Data transferred:               3.03 MB
> Response time:                  0.11 secs
> Transaction rate:              83.69 trans/sec
> Throughput:                     0.21 MB/sec
> Concurrency:                    9.30
> Successful transactions:        1205
> Failed transactions:               0
> Longest transaction:            6.29
> Shortest transaction:           0.01
> 
> Can you reproduce the problem with siege?  What platform are you
> running on?  Can you reproduce the problem when the client is on the
> same machine as the server?
> 
> It'd be interested to learn where the
> SB-BSD-SOCKETS:NOT-CONNECTED-ERROR is actually signalled from.  To
> debug, you might set *BREAK-ON-SIGNALS* to
> 'SB-BSD-SOCKETS:NOT-CONNECTED-ERROR and post the backtrace.
> 
> -Hans
> 
> 2009/7/3 Peter Stiernstr?m <peter.stiernstrom at blixtvik.se>:
> I don't know if this have come up earlier or if it is a known problem.
> If so I am sorry for bringing it up again. A quick look through the
> archives turned up a non-caught sbcl socket timeout error with the
> obvious fix of adding an error translation to the usocket sbcl backend
> error map. I expect this to be somewhat similar.
> 
> When stressing hunchentoot with a number of connection like so:
> 
> for i in $(seq 1 20); do nmap -sT -p 80 <hostname> ;done
> 
> Hunchentoot (last 1.0 release) stops responding after not having caught
> a SB-BSD-SOCKETS:NOT-CONNECTED-ERROR thus being easily DOSed.
> 
> I was hoping that there would be an obvious similar mapping missing but
> I don't know my way around hunchentoot to figure out what to map
> SB-BSD-SOCKETS:NOT-CONNECTED-ERROR to.
> 
> I am seeing this problem on a regular basis and for now it always
> prompts a full restart.
> 
> I am using usocket 0.4.1 with hunchentoot 1.0.0.
> 
> /Peter
>>
_______________________________________________
tbnl-devel site list
tbnl-devel at common-lisp.net
http://common-lisp.net/mailman/listinfo/tbnl-devel
>>

> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel

- --
Med v?nlig h?lsning,

Peter Stiernstr?m
0708-810932
Blixtvik AB
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkpRpkUACgkQ0brSZD05ZzDADQCdHqzYZg8+Aza0hVvP+gT/3Oa3
PS0AoLv8ni4rQ5IF5qSUEXzqK4Rfu/7y
=vZYn
-----END PGP SIGNATURE-----



From hans.huebner at gmail.com  Mon Jul  6 08:35:46 2009
From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Mon, 6 Jul 2009 10:35:46 +0200
Subject: [hunchentoot-devel] Hunchentoot effective DOS-attack
In-Reply-To: <4A51A645.3000909@blixtvik.se>
References: <4A4DE786.90702@blixtvik.se>
	<fd2982320907051439w6bd92e6bu516a66b2cb02619c@mail.gmail.com> 
	<4A51A645.3000909@blixtvik.se>
Message-ID: <fd2982320907060135l1eb0fa5dx32e2daf115197c6c@mail.gmail.com>

Hi Peter,

2009/7/6 Peter Stiernstr?m <peter.stiernstrom at blixtvik.se>
> I had a quick peek at client-as-string and it does indeed not handle the
> sb-bsd-sockets:not-connected-error and if I put a handler-case around
> body of client-as-string returning nil when the exception appears I can
> not reproduce my problem anymore.
>
> This wouldn't provide a portable solution though :-P

This really is a bug that requires fixing in usocket.  There are
multiple issues:

- As shown in the backtrace, the problem is that the getpeername()
call fails for a socket that is not connected anymore.  SBCL does the
right thing by signalling a condition.  Other implementations (I
checked CCL) seem to behave differently, i.e. return NIL in such a
case.

- Usocket does not unify the behavior, so the implementation specific
condition percolates to the caller, Hunchentoot in this case.

- Hunchentoot is not prepared to handle conditions when creating a new
worker thread.  The call to CLIENT-AS-STRING is made when creating the
name for the handler process of a new incoming connection, and that is
done in the context of the server thread.  Therefore, the signalled
condition will stop the acceptor process.

I spent some thoughts on how a "portable solution" would look like,
but given that the Lisp implementations vary greatly in behavior,
fixing usocket would be a pretty large task that I don't have the time
to do right now.  Thus, I would propose this patch:

http://bknr.net/trac/changeset/4428?format=diff&new=4428

It handles all conditions that are signaled during worker process
creation, under the theory that we want to prevent the acceptor
process from crashing under all circumstances.  This is not a clean
solution in that it may paper over bugs, but given the limited number
of function invocations that are surrounded by a HANDLER-CASE, I'd say
that this is a proper intermediate fix.

Please give it a try and let me know if it solves the problem for you.

-Hans



From peter.stiernstrom at blixtvik.se  Mon Jul  6 09:09:24 2009
From: peter.stiernstrom at blixtvik.se (=?ISO-8859-1?Q?Peter_Stiernstr=F6m?=)
Date: Mon, 06 Jul 2009 11:09:24 +0200
Subject: [hunchentoot-devel] Hunchentoot effective DOS-attack
In-Reply-To: <fd2982320907060135l1eb0fa5dx32e2daf115197c6c@mail.gmail.com>
References: <4A4DE786.90702@blixtvik.se>	<fd2982320907051439w6bd92e6bu516a66b2cb02619c@mail.gmail.com>
	<4A51A645.3000909@blixtvik.se>
	<fd2982320907060135l1eb0fa5dx32e2daf115197c6c@mail.gmail.com>
Message-ID: <4A51BF44.8080209@blixtvik.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Hans,

Hans H?bner wrote:
> Hi Peter,
> 
> 2009/7/6 Peter Stiernstr?m <peter.stiernstrom at blixtvik.se>
>> I had a quick peek at client-as-string and it does indeed not handle the
>> sb-bsd-sockets:not-connected-error and if I put a handler-case around
>> body of client-as-string returning nil when the exception appears I can
>> not reproduce my problem anymore.
>>
>> This wouldn't provide a portable solution though :-P
> 
> This really is a bug that requires fixing in usocket.  There are
> multiple issues:
> 
> - As shown in the backtrace, the problem is that the getpeername()
> call fails for a socket that is not connected anymore.  SBCL does the
> right thing by signalling a condition.  Other implementations (I
> checked CCL) seem to behave differently, i.e. return NIL in such a
> case.
> 
> - Usocket does not unify the behavior, so the implementation specific
> condition percolates to the caller, Hunchentoot in this case.
> 
> - Hunchentoot is not prepared to handle conditions when creating a new
> worker thread.  The call to CLIENT-AS-STRING is made when creating the
> name for the handler process of a new incoming connection, and that is
> done in the context of the server thread.  Therefore, the signalled
> condition will stop the acceptor process.
> 
> I spent some thoughts on how a "portable solution" would look like,
> but given that the Lisp implementations vary greatly in behavior,
> fixing usocket would be a pretty large task that I don't have the time
> to do right now.  Thus, I would propose this patch:
> 
> http://bknr.net/trac/changeset/4428?format=diff&new=4428
> 
> It handles all conditions that are signaled during worker process
> creation, under the theory that we want to prevent the acceptor
> process from crashing under all circumstances.  This is not a clean
> solution in that it may paper over bugs, but given the limited number
> of function invocations that are surrounded by a HANDLER-CASE, I'd say
> that this is a proper intermediate fix.
> 
> Please give it a try and let me know if it solves the problem for you.

I tried your suggested patch but I can't seem to be able to get it to
catch the exception for me. Were you able to duplicate the error
yourself to verify that the suggested patch does indeed work? Since I am
using the 1.0.0 hunchentoot release I couldn't just apply your patch but
added the handler-case by hand and thus ended up with this in
taskmaster.lisp:

(defmethod handle-incoming-connection ((taskmaster
one-thread-per-connection-taskmaster) handle)
  (incf *worker-counter*)
  ;; check if we need to perform a global GC
  (when (and *cleanup-interval*
             (zerop (mod *worker-counter* *cleanup-interval*)))
    (when *cleanup-function*
      (funcall *cleanup-function*)))
  (handler-case
      (mp:process-run-function (format nil "Hunchentoot worker \(client:
~{~A:~A~})"
                                       (multiple-value-list
                                        (get-peer-address-and-port handle)))
                               nil #'process-connection
                               (taskmaster-acceptor taskmaster) handle)
    (error (cond)
      (log-message *lisp-errors-log-level*	
                   "Error while creating worker thread for new incoming
connection: ~A" cond))))

/Peter


> 
> -Hans
> 
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel

- --
Med v?nlig h?lsning,

Peter Stiernstr?m
0708-810932
Blixtvik AB
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkpRv0QACgkQ0brSZD05ZzDvgQCcDecaau+Hq35HtXoZkrg0EwRz
cLAAnR6IgD6sE5PxkD6bs1Jf6wj0b+N7
=eUDk
-----END PGP SIGNATURE-----



From hans.huebner at gmail.com  Mon Jul  6 09:15:04 2009
From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Mon, 6 Jul 2009 11:15:04 +0200
Subject: [hunchentoot-devel] Hunchentoot effective DOS-attack
In-Reply-To: <4A51BF44.8080209@blixtvik.se>
References: <4A4DE786.90702@blixtvik.se>
	<fd2982320907051439w6bd92e6bu516a66b2cb02619c@mail.gmail.com> 
	<4A51A645.3000909@blixtvik.se>
	<fd2982320907060135l1eb0fa5dx32e2daf115197c6c@mail.gmail.com> 
	<4A51BF44.8080209@blixtvik.se>
Message-ID: <fd2982320907060215t542cd599m3f3207e99e520d8a@mail.gmail.com>

Peter,

sorry, I am not able to reproduce the problem myself, so I made the
patch blindly and made a mistake, working on the Lispworks code rather
than the portable code that affects you.  Please look at the first
hunk of this diff:

http://bknr.net/trac/changeset/4430?format=diff&new=4430

and let me know if that does it for you.

Sorry,
Hans

On Mon, Jul 6, 2009 at 11:09, Peter
Stiernstr?m<peter.stiernstrom at blixtvik.se> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Hans,
>
> Hans H?bner wrote:
>> Hi Peter,
>>
>> 2009/7/6 Peter Stiernstr?m <peter.stiernstrom at blixtvik.se>
>>> I had a quick peek at client-as-string and it does indeed not handle the
>>> sb-bsd-sockets:not-connected-error and if I put a handler-case around
>>> body of client-as-string returning nil when the exception appears I can
>>> not reproduce my problem anymore.
>>>
>>> This wouldn't provide a portable solution though :-P
>>
>> This really is a bug that requires fixing in usocket. ?There are
>> multiple issues:
>>
>> - As shown in the backtrace, the problem is that the getpeername()
>> call fails for a socket that is not connected anymore. ?SBCL does the
>> right thing by signalling a condition. ?Other implementations (I
>> checked CCL) seem to behave differently, i.e. return NIL in such a
>> case.
>>
>> - Usocket does not unify the behavior, so the implementation specific
>> condition percolates to the caller, Hunchentoot in this case.
>>
>> - Hunchentoot is not prepared to handle conditions when creating a new
>> worker thread. ?The call to CLIENT-AS-STRING is made when creating the
>> name for the handler process of a new incoming connection, and that is
>> done in the context of the server thread. ?Therefore, the signalled
>> condition will stop the acceptor process.
>>
>> I spent some thoughts on how a "portable solution" would look like,
>> but given that the Lisp implementations vary greatly in behavior,
>> fixing usocket would be a pretty large task that I don't have the time
>> to do right now. ?Thus, I would propose this patch:
>>
>> http://bknr.net/trac/changeset/4428?format=diff&new=4428
>>
>> It handles all conditions that are signaled during worker process
>> creation, under the theory that we want to prevent the acceptor
>> process from crashing under all circumstances. ?This is not a clean
>> solution in that it may paper over bugs, but given the limited number
>> of function invocations that are surrounded by a HANDLER-CASE, I'd say
>> that this is a proper intermediate fix.
>>
>> Please give it a try and let me know if it solves the problem for you.
>
> I tried your suggested patch but I can't seem to be able to get it to
> catch the exception for me. Were you able to duplicate the error
> yourself to verify that the suggested patch does indeed work? Since I am
> using the 1.0.0 hunchentoot release I couldn't just apply your patch but
> added the handler-case by hand and thus ended up with this in
> taskmaster.lisp:
>
> (defmethod handle-incoming-connection ((taskmaster
> one-thread-per-connection-taskmaster) handle)
> ?(incf *worker-counter*)
> ?;; check if we need to perform a global GC
> ?(when (and *cleanup-interval*
> ? ? ? ? ? ? (zerop (mod *worker-counter* *cleanup-interval*)))
> ? ?(when *cleanup-function*
> ? ? ?(funcall *cleanup-function*)))
> ?(handler-case
> ? ? ?(mp:process-run-function (format nil "Hunchentoot worker \(client:
> ~{~A:~A~})"
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? (multiple-value-list
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?(get-peer-address-and-port handle)))
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? nil #'process-connection
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? (taskmaster-acceptor taskmaster) handle)
> ? ?(error (cond)
> ? ? ?(log-message *lisp-errors-log-level*
> ? ? ? ? ? ? ? ? ? "Error while creating worker thread for new incoming
> connection: ~A" cond))))
>
> /Peter
>
>
>>
>> -Hans
>>
>> _______________________________________________
>> tbnl-devel site list
>> tbnl-devel at common-lisp.net
>> http://common-lisp.net/mailman/listinfo/tbnl-devel
>
> - --
> Med v?nlig h?lsning,
>
> Peter Stiernstr?m
> 0708-810932
> Blixtvik AB
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkpRv0QACgkQ0brSZD05ZzDvgQCcDecaau+Hq35HtXoZkrg0EwRz
> cLAAnR6IgD6sE5PxkD6bs1Jf6wj0b+N7
> =eUDk
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>



From peter.stiernstrom at blixtvik.se  Mon Jul  6 10:52:15 2009
From: peter.stiernstrom at blixtvik.se (=?ISO-8859-1?Q?Peter_Stiernstr=F6m?=)
Date: Mon, 06 Jul 2009 12:52:15 +0200
Subject: [hunchentoot-devel] Hunchentoot effective DOS-attack
In-Reply-To: <fd2982320907060215t542cd599m3f3207e99e520d8a@mail.gmail.com>
References: <4A4DE786.90702@blixtvik.se>	<fd2982320907051439w6bd92e6bu516a66b2cb02619c@mail.gmail.com>
	<4A51A645.3000909@blixtvik.se>	<fd2982320907060135l1eb0fa5dx32e2daf115197c6c@mail.gmail.com>
	<4A51BF44.8080209@blixtvik.se>
	<fd2982320907060215t542cd599m3f3207e99e520d8a@mail.gmail.com>
Message-ID: <4A51D75F.5090303@blixtvik.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hans,

I should have realised I was editing the lispworks implementation myself
had I only had a cup of coffee this morning :-P

Now when I tried your patch out I still get hangups but this is another
kind of hangup:

debugger invoked on a UNBOUND-VARIABLE in thread #<THREAD "Hunchentoot
listener (*:8000)" RUNNING {AD467D1}>:
  The variable HUNCHENTOOT:*ACCEPTOR* is unbound.

I am trying this out with the hunchentoot default page by the way.

/Peter

Hans H?bner wrote:
> Peter,
> 
> sorry, I am not able to reproduce the problem myself, so I made the
> patch blindly and made a mistake, working on the Lispworks code rather
> than the portable code that affects you.  Please look at the first
> hunk of this diff:
> 
> http://bknr.net/trac/changeset/4430?format=diff&new=4430
> 
> and let me know if that does it for you.
> 
> Sorry,
> Hans
> 
> On Mon, Jul 6, 2009 at 11:09, Peter
> Stiernstr?m<peter.stiernstrom at blixtvik.se> wrote:
> Hi Hans,
> 
> Hans H?bner wrote:
>>>> Hi Peter,
>>>>
>>>> 2009/7/6 Peter Stiernstr?m <peter.stiernstrom at blixtvik.se>
>>>>> I had a quick peek at client-as-string and it does indeed not handle the
>>>>> sb-bsd-sockets:not-connected-error and if I put a handler-case around
>>>>> body of client-as-string returning nil when the exception appears I can
>>>>> not reproduce my problem anymore.
>>>>>
>>>>> This wouldn't provide a portable solution though :-P
>>>> This really is a bug that requires fixing in usocket.  There are
>>>> multiple issues:
>>>>
>>>> - As shown in the backtrace, the problem is that the getpeername()
>>>> call fails for a socket that is not connected anymore.  SBCL does the
>>>> right thing by signalling a condition.  Other implementations (I
>>>> checked CCL) seem to behave differently, i.e. return NIL in such a
>>>> case.
>>>>
>>>> - Usocket does not unify the behavior, so the implementation specific
>>>> condition percolates to the caller, Hunchentoot in this case.
>>>>
>>>> - Hunchentoot is not prepared to handle conditions when creating a new
>>>> worker thread.  The call to CLIENT-AS-STRING is made when creating the
>>>> name for the handler process of a new incoming connection, and that is
>>>> done in the context of the server thread.  Therefore, the signalled
>>>> condition will stop the acceptor process.
>>>>
>>>> I spent some thoughts on how a "portable solution" would look like,
>>>> but given that the Lisp implementations vary greatly in behavior,
>>>> fixing usocket would be a pretty large task that I don't have the time
>>>> to do right now.  Thus, I would propose this patch:
>>>>
>>>> http://bknr.net/trac/changeset/4428?format=diff&new=4428
>>>>
>>>> It handles all conditions that are signaled during worker process
>>>> creation, under the theory that we want to prevent the acceptor
>>>> process from crashing under all circumstances.  This is not a clean
>>>> solution in that it may paper over bugs, but given the limited number
>>>> of function invocations that are surrounded by a HANDLER-CASE, I'd say
>>>> that this is a proper intermediate fix.
>>>>
>>>> Please give it a try and let me know if it solves the problem for you.
> I tried your suggested patch but I can't seem to be able to get it to
> catch the exception for me. Were you able to duplicate the error
> yourself to verify that the suggested patch does indeed work? Since I am
> using the 1.0.0 hunchentoot release I couldn't just apply your patch but
> added the handler-case by hand and thus ended up with this in
> taskmaster.lisp:
> 
> (defmethod handle-incoming-connection ((taskmaster
> one-thread-per-connection-taskmaster) handle)
>  (incf *worker-counter*)
>  ;; check if we need to perform a global GC
>  (when (and *cleanup-interval*
>             (zerop (mod *worker-counter* *cleanup-interval*)))
>    (when *cleanup-function*
>      (funcall *cleanup-function*)))
>  (handler-case
>      (mp:process-run-function (format nil "Hunchentoot worker \(client:
> ~{~A:~A~})"
>                                       (multiple-value-list
>                                        (get-peer-address-and-port handle)))
>                               nil #'process-connection
>                               (taskmaster-acceptor taskmaster) handle)
>    (error (cond)
>      (log-message *lisp-errors-log-level*
>                   "Error while creating worker thread for new incoming
> connection: ~A" cond))))
> 
> /Peter
> 
> 
>>>> -Hans
>>>>
>>>> _______________________________________________
>>>> tbnl-devel site list
>>>> tbnl-devel at common-lisp.net
>>>> http://common-lisp.net/mailman/listinfo/tbnl-devel
>>
_______________________________________________
tbnl-devel site list
tbnl-devel at common-lisp.net
http://common-lisp.net/mailman/listinfo/tbnl-devel
>>

> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel

- --
Med v?nlig h?lsning,

Peter Stiernstr?m
0708-810932
Blixtvik AB
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkpR114ACgkQ0brSZD05ZzAp6ACdH3j38ycjcZqpjJiTdoZUubHn
JQUAoJipg3faXED9AO51Y4LlKvlPQZLE
=Vai6
-----END PGP SIGNATURE-----



From hans.huebner at gmail.com  Mon Jul  6 10:56:29 2009
From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Mon, 6 Jul 2009 12:56:29 +0200
Subject: [hunchentoot-devel] Hunchentoot effective DOS-attack
In-Reply-To: <4A51D75F.5090303@blixtvik.se>
References: <4A4DE786.90702@blixtvik.se>
	<fd2982320907051439w6bd92e6bu516a66b2cb02619c@mail.gmail.com> 
	<4A51A645.3000909@blixtvik.se>
	<fd2982320907060135l1eb0fa5dx32e2daf115197c6c@mail.gmail.com> 
	<4A51BF44.8080209@blixtvik.se>
	<fd2982320907060215t542cd599m3f3207e99e520d8a@mail.gmail.com> 
	<4A51D75F.5090303@blixtvik.se>
Message-ID: <fd2982320907060356ib6cb484ie4da6a686f18cb7d@mail.gmail.com>

Peter, as I cannot reproduce the problem myself, can you please post a
stack backtrace?  Thanks!

2009/7/6 Peter Stiernstr?m <peter.stiernstrom at blixtvik.se>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hans,
>
> I should have realised I was editing the lispworks implementation myself
> had I only had a cup of coffee this morning :-P
>
> Now when I tried your patch out I still get hangups but this is another
> kind of hangup:
>
> debugger invoked on a UNBOUND-VARIABLE in thread #<THREAD "Hunchentoot
> listener (*:8000)" RUNNING {AD467D1}>:
> ?The variable HUNCHENTOOT:*ACCEPTOR* is unbound.
>
> I am trying this out with the hunchentoot default page by the way.
>
> /Peter
>
> Hans H?bner wrote:
>> Peter,
>>
>> sorry, I am not able to reproduce the problem myself, so I made the
>> patch blindly and made a mistake, working on the Lispworks code rather
>> than the portable code that affects you. ?Please look at the first
>> hunk of this diff:
>>
>> http://bknr.net/trac/changeset/4430?format=diff&new=4430
>>
>> and let me know if that does it for you.
>>
>> Sorry,
>> Hans
>>
>> On Mon, Jul 6, 2009 at 11:09, Peter
>> Stiernstr?m<peter.stiernstrom at blixtvik.se> wrote:
>> Hi Hans,
>>
>> Hans H?bner wrote:
>>>>> Hi Peter,
>>>>>
>>>>> 2009/7/6 Peter Stiernstr?m <peter.stiernstrom at blixtvik.se>
>>>>>> I had a quick peek at client-as-string and it does indeed not handle the
>>>>>> sb-bsd-sockets:not-connected-error and if I put a handler-case around
>>>>>> body of client-as-string returning nil when the exception appears I can
>>>>>> not reproduce my problem anymore.
>>>>>>
>>>>>> This wouldn't provide a portable solution though :-P
>>>>> This really is a bug that requires fixing in usocket. ?There are
>>>>> multiple issues:
>>>>>
>>>>> - As shown in the backtrace, the problem is that the getpeername()
>>>>> call fails for a socket that is not connected anymore. ?SBCL does the
>>>>> right thing by signalling a condition. ?Other implementations (I
>>>>> checked CCL) seem to behave differently, i.e. return NIL in such a
>>>>> case.
>>>>>
>>>>> - Usocket does not unify the behavior, so the implementation specific
>>>>> condition percolates to the caller, Hunchentoot in this case.
>>>>>
>>>>> - Hunchentoot is not prepared to handle conditions when creating a new
>>>>> worker thread. ?The call to CLIENT-AS-STRING is made when creating the
>>>>> name for the handler process of a new incoming connection, and that is
>>>>> done in the context of the server thread. ?Therefore, the signalled
>>>>> condition will stop the acceptor process.
>>>>>
>>>>> I spent some thoughts on how a "portable solution" would look like,
>>>>> but given that the Lisp implementations vary greatly in behavior,
>>>>> fixing usocket would be a pretty large task that I don't have the time
>>>>> to do right now. ?Thus, I would propose this patch:
>>>>>
>>>>> http://bknr.net/trac/changeset/4428?format=diff&new=4428
>>>>>
>>>>> It handles all conditions that are signaled during worker process
>>>>> creation, under the theory that we want to prevent the acceptor
>>>>> process from crashing under all circumstances. ?This is not a clean
>>>>> solution in that it may paper over bugs, but given the limited number
>>>>> of function invocations that are surrounded by a HANDLER-CASE, I'd say
>>>>> that this is a proper intermediate fix.
>>>>>
>>>>> Please give it a try and let me know if it solves the problem for you.
>> I tried your suggested patch but I can't seem to be able to get it to
>> catch the exception for me. Were you able to duplicate the error
>> yourself to verify that the suggested patch does indeed work? Since I am
>> using the 1.0.0 hunchentoot release I couldn't just apply your patch but
>> added the handler-case by hand and thus ended up with this in
>> taskmaster.lisp:
>>
>> (defmethod handle-incoming-connection ((taskmaster
>> one-thread-per-connection-taskmaster) handle)
>> ?(incf *worker-counter*)
>> ?;; check if we need to perform a global GC
>> ?(when (and *cleanup-interval*
>> ? ? ? ? ? ? (zerop (mod *worker-counter* *cleanup-interval*)))
>> ? ?(when *cleanup-function*
>> ? ? ?(funcall *cleanup-function*)))
>> ?(handler-case
>> ? ? ?(mp:process-run-function (format nil "Hunchentoot worker \(client:
>> ~{~A:~A~})"
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? (multiple-value-list
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?(get-peer-address-and-port handle)))
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? nil #'process-connection
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? (taskmaster-acceptor taskmaster) handle)
>> ? ?(error (cond)
>> ? ? ?(log-message *lisp-errors-log-level*
>> ? ? ? ? ? ? ? ? ? "Error while creating worker thread for new incoming
>> connection: ~A" cond))))
>>
>> /Peter
>>
>>
>>>>> -Hans
>>>>>
>>>>> _______________________________________________
>>>>> tbnl-devel site list
>>>>> tbnl-devel at common-lisp.net
>>>>> http://common-lisp.net/mailman/listinfo/tbnl-devel
>>>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>>>
>
>> _______________________________________________
>> tbnl-devel site list
>> tbnl-devel at common-lisp.net
>> http://common-lisp.net/mailman/listinfo/tbnl-devel
>
> - --
> Med v?nlig h?lsning,
>
> Peter Stiernstr?m
> 0708-810932
> Blixtvik AB
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkpR114ACgkQ0brSZD05ZzAp6ACdH3j38ycjcZqpjJiTdoZUubHn
> JQUAoJipg3faXED9AO51Y4LlKvlPQZLE
> =Vai6
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>



From peter.stiernstrom at blixtvik.se  Mon Jul  6 11:21:43 2009
From: peter.stiernstrom at blixtvik.se (=?ISO-8859-1?Q?Peter_Stiernstr=F6m?=)
Date: Mon, 06 Jul 2009 13:21:43 +0200
Subject: [hunchentoot-devel] Hunchentoot effective DOS-attack
In-Reply-To: <fd2982320907060356ib6cb484ie4da6a686f18cb7d@mail.gmail.com>
References: <4A4DE786.90702@blixtvik.se>	<fd2982320907051439w6bd92e6bu516a66b2cb02619c@mail.gmail.com>
	<4A51A645.3000909@blixtvik.se>	<fd2982320907060135l1eb0fa5dx32e2daf115197c6c@mail.gmail.com>
	<4A51BF44.8080209@blixtvik.se>	<fd2982320907060215t542cd599m3f3207e99e520d8a@mail.gmail.com>
	<4A51D75F.5090303@blixtvik.se>
	<fd2982320907060356ib6cb484ie4da6a686f18cb7d@mail.gmail.com>
Message-ID: <4A51DE47.2040301@blixtvik.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello Hans,

Hans H?bner wrote:
> Peter, as I cannot reproduce the problem myself, can you please post a
> stack backtrace?  Thanks!

The variable HUNCHENTOOT:*ACCEPTOR* is unbound.
BREAK was entered because of *BREAK-ON-SIGNALS* (now rebound to NIL).
   [Condition of type SIMPLE-CONDITION]

Restarts:
 0: [CONTINUE] Return from BREAK.
 1: [REASSIGN] Return from BREAK and assign a new value to
*BREAK-ON-SIGNALS*.
 2: [TERMINATE-THREAD] Terminate this thread (#<THREAD "Hunchentoot
listener (*:8000)" RUNNING {C42AAE9}>)

Backtrace:
  0: (BREAK "~A~%BREAK was entered because of *BREAK-ON-SIGNALS* ~\n
                (now rebound to NIL)." #<UNBOUND-VARIABLE *ACCEPTOR*
{AD37FC1}>)
  1: (SIGNAL #<UNBOUND-VARIABLE *ACCEPTOR* {AD37FC1}>)[:EXTERNAL]
  2: (ERROR UNBOUND-VARIABLE)[:EXTERNAL]
  3: (SB-KERNEL::UNBOUND-SYMBOL-ERROR-HANDLER #<unavailable argument>
#.(SB-SYS:INT-SAP #XB5DFFEF0) #<SB-ALIEN-INTERNALS:ALIEN-VALUE :SAP
#XB5DFFBDC :TYPE (* (STRUCT SB-VM::OS-CONTEXT-T-STRUCT))> (14))
  4: (SB-KERNEL::UNBOUND-SYMBOL-ERROR-HANDLER #<unavailable argument>
#.(SB-SYS:INT-SAP #XB5DFFEF0) #<SB-ALIEN-INTERNALS:ALIEN-VALUE :SAP
#XB5DFFBDC :TYPE (* (STRUCT SB-VM::OS-CONTEXT-T-STRUCT))> (14))[:EX..
  5: (SB-KERNEL:INTERNAL-ERROR #.(SB-SYS:INT-SAP #XB5DFFBDC)
#<unavailable argument>)
  6: ("foreign function: #x806480C")
  7: ("foreign function: #x8052BCC")
  8: ("foreign function: #x8056BD3")
  9: (HUNCHENTOOT:LOG-MESSAGE :ERROR "Error while creating worker thread
for new incoming connection: ~A")[:EXTERNAL]
 10: ((SB-PCL::FAST-METHOD HUNCHENTOOT:HANDLE-INCOMING-CONNECTION
(HUNCHENTOOT:ONE-THREAD-PER-CONNECTION-TASKMASTER T)) ..)
 11: ((SB-PCL::FAST-METHOD HUNCHENTOOT:ACCEPT-CONNECTIONS
(HUNCHENTOOT:ACCEPTOR)) #<unavailable argument> #<unavailable argument>
#<HUNCHENTOOT:ACCEPTOR (host *, port 8000)>)
 12: ((FLET SB-THREAD::WITH-MUTEX-THUNK))
 13: ((FLET #:WITHOUT-INTERRUPTS-BODY-[CALL-WITH-MUTEX]477))
 14: (SB-THREAD::CALL-WITH-MUTEX ..)
 15: ((LAMBDA ()))
 16: ("foreign function: #x806480C")
 17: ("foreign function: #x8052C21")
 18: ("foreign function: #x805BD9D")
 19: ("foreign function: #xB7FB84C0")

I found that not attempting to log a message solved this remaining problem.

Thank you very much for your help!

/Peter

> 
> 2009/7/6 Peter Stiernstr?m <peter.stiernstrom at blixtvik.se>:
> Hans,
> 
> I should have realised I was editing the lispworks implementation myself
> had I only had a cup of coffee this morning :-P
> 
> Now when I tried your patch out I still get hangups but this is another
> kind of hangup:
> 
> debugger invoked on a UNBOUND-VARIABLE in thread #<THREAD "Hunchentoot
> listener (*:8000)" RUNNING {AD467D1}>:
>  The variable HUNCHENTOOT:*ACCEPTOR* is unbound.
> 
> I am trying this out with the hunchentoot default page by the way.
> 
> /Peter
> 
> Hans H?bner wrote:
>>>> Peter,
>>>>
>>>> sorry, I am not able to reproduce the problem myself, so I made the
>>>> patch blindly and made a mistake, working on the Lispworks code rather
>>>> than the portable code that affects you.  Please look at the first
>>>> hunk of this diff:
>>>>
>>>> http://bknr.net/trac/changeset/4430?format=diff&new=4430
>>>>
>>>> and let me know if that does it for you.
>>>>
>>>> Sorry,
>>>> Hans
>>>>
>>>> On Mon, Jul 6, 2009 at 11:09, Peter
>>>> Stiernstr?m<peter.stiernstrom at blixtvik.se> wrote:
>>>> Hi Hans,
>>>>
>>>> Hans H?bner wrote:
>>>>>>> Hi Peter,
>>>>>>>
>>>>>>> 2009/7/6 Peter Stiernstr?m <peter.stiernstrom at blixtvik.se>
>>>>>>>> I had a quick peek at client-as-string and it does indeed not handle the
>>>>>>>> sb-bsd-sockets:not-connected-error and if I put a handler-case around
>>>>>>>> body of client-as-string returning nil when the exception appears I can
>>>>>>>> not reproduce my problem anymore.
>>>>>>>>
>>>>>>>> This wouldn't provide a portable solution though :-P
>>>>>>> This really is a bug that requires fixing in usocket.  There are
>>>>>>> multiple issues:
>>>>>>>
>>>>>>> - As shown in the backtrace, the problem is that the getpeername()
>>>>>>> call fails for a socket that is not connected anymore.  SBCL does the
>>>>>>> right thing by signalling a condition.  Other implementations (I
>>>>>>> checked CCL) seem to behave differently, i.e. return NIL in such a
>>>>>>> case.
>>>>>>>
>>>>>>> - Usocket does not unify the behavior, so the implementation specific
>>>>>>> condition percolates to the caller, Hunchentoot in this case.
>>>>>>>
>>>>>>> - Hunchentoot is not prepared to handle conditions when creating a new
>>>>>>> worker thread.  The call to CLIENT-AS-STRING is made when creating the
>>>>>>> name for the handler process of a new incoming connection, and that is
>>>>>>> done in the context of the server thread.  Therefore, the signalled
>>>>>>> condition will stop the acceptor process.
>>>>>>>
>>>>>>> I spent some thoughts on how a "portable solution" would look like,
>>>>>>> but given that the Lisp implementations vary greatly in behavior,
>>>>>>> fixing usocket would be a pretty large task that I don't have the time
>>>>>>> to do right now.  Thus, I would propose this patch:
>>>>>>>
>>>>>>> http://bknr.net/trac/changeset/4428?format=diff&new=4428
>>>>>>>
>>>>>>> It handles all conditions that are signaled during worker process
>>>>>>> creation, under the theory that we want to prevent the acceptor
>>>>>>> process from crashing under all circumstances.  This is not a clean
>>>>>>> solution in that it may paper over bugs, but given the limited number
>>>>>>> of function invocations that are surrounded by a HANDLER-CASE, I'd say
>>>>>>> that this is a proper intermediate fix.
>>>>>>>
>>>>>>> Please give it a try and let me know if it solves the problem for you.
>>>> I tried your suggested patch but I can't seem to be able to get it to
>>>> catch the exception for me. Were you able to duplicate the error
>>>> yourself to verify that the suggested patch does indeed work? Since I am
>>>> using the 1.0.0 hunchentoot release I couldn't just apply your patch but
>>>> added the handler-case by hand and thus ended up with this in
>>>> taskmaster.lisp:
>>>>
>>>> (defmethod handle-incoming-connection ((taskmaster
>>>> one-thread-per-connection-taskmaster) handle)
>>>>  (incf *worker-counter*)
>>>>  ;; check if we need to perform a global GC
>>>>  (when (and *cleanup-interval*
>>>>             (zerop (mod *worker-counter* *cleanup-interval*)))
>>>>    (when *cleanup-function*
>>>>      (funcall *cleanup-function*)))
>>>>  (handler-case
>>>>      (mp:process-run-function (format nil "Hunchentoot worker \(client:
>>>> ~{~A:~A~})"
>>>>                                       (multiple-value-list
>>>>                                        (get-peer-address-and-port handle)))
>>>>                               nil #'process-connection
>>>>                               (taskmaster-acceptor taskmaster) handle)
>>>>    (error (cond)
>>>>      (log-message *lisp-errors-log-level*
>>>>                   "Error while creating worker thread for new incoming
>>>> connection: ~A" cond))))
>>>>
>>>> /Peter
>>>>
>>>>
>>>>>>> -Hans
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> tbnl-devel site list
>>>>>>> tbnl-devel at common-lisp.net
>>>>>>> http://common-lisp.net/mailman/listinfo/tbnl-devel
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>>>> _______________________________________________
>>>> tbnl-devel site list
>>>> tbnl-devel at common-lisp.net
>>>> http://common-lisp.net/mailman/listinfo/tbnl-devel
>>
_______________________________________________
tbnl-devel site list
tbnl-devel at common-lisp.net
http://common-lisp.net/mailman/listinfo/tbnl-devel
>>

> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel

- --
Med v?nlig h?lsning,

Peter Stiernstr?m
0708-810932
Blixtvik AB
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkpR3kcACgkQ0brSZD05ZzDxywCdFzn0tdVZb35stsaCZL4uPSw5
N5wAn1FC1VTcJyNV+c+bzIpLFfTAyMfW
=k68p
-----END PGP SIGNATURE-----



From hans.huebner at gmail.com  Mon Jul  6 11:22:40 2009
From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Mon, 6 Jul 2009 13:22:40 +0200
Subject: [hunchentoot-devel] Hunchentoot effective DOS-attack
In-Reply-To: <4A51DE47.2040301@blixtvik.se>
References: <4A4DE786.90702@blixtvik.se>
	<fd2982320907051439w6bd92e6bu516a66b2cb02619c@mail.gmail.com> 
	<4A51A645.3000909@blixtvik.se>
	<fd2982320907060135l1eb0fa5dx32e2daf115197c6c@mail.gmail.com> 
	<4A51BF44.8080209@blixtvik.se>
	<fd2982320907060215t542cd599m3f3207e99e520d8a@mail.gmail.com> 
	<4A51D75F.5090303@blixtvik.se>
	<fd2982320907060356ib6cb484ie4da6a686f18cb7d@mail.gmail.com> 
	<4A51DE47.2040301@blixtvik.se>
Message-ID: <fd2982320907060422t588362cbsa09039a6afd62b8@mail.gmail.com>

Peter,

try this:

http://bknr.net/trac/changeset/4434?format=diff&new=4434

-Hans

On Mon, Jul 6, 2009 at 13:21, Peter
Stiernstr?m<peter.stiernstrom at blixtvik.se> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hello Hans,
>
> Hans H?bner wrote:
>> Peter, as I cannot reproduce the problem myself, can you please post a
>> stack backtrace? ?Thanks!
>
> The variable HUNCHENTOOT:*ACCEPTOR* is unbound.
> BREAK was entered because of *BREAK-ON-SIGNALS* (now rebound to NIL).
> ? [Condition of type SIMPLE-CONDITION]
>
> Restarts:
> ?0: [CONTINUE] Return from BREAK.
> ?1: [REASSIGN] Return from BREAK and assign a new value to
> *BREAK-ON-SIGNALS*.
> ?2: [TERMINATE-THREAD] Terminate this thread (#<THREAD "Hunchentoot
> listener (*:8000)" RUNNING {C42AAE9}>)
>
> Backtrace:
> ?0: (BREAK "~A~%BREAK was entered because of *BREAK-ON-SIGNALS* ~\n
> ? ? ? ? ? ? ? ?(now rebound to NIL)." #<UNBOUND-VARIABLE *ACCEPTOR*
> {AD37FC1}>)
> ?1: (SIGNAL #<UNBOUND-VARIABLE *ACCEPTOR* {AD37FC1}>)[:EXTERNAL]
> ?2: (ERROR UNBOUND-VARIABLE)[:EXTERNAL]
> ?3: (SB-KERNEL::UNBOUND-SYMBOL-ERROR-HANDLER #<unavailable argument>
> #.(SB-SYS:INT-SAP #XB5DFFEF0) #<SB-ALIEN-INTERNALS:ALIEN-VALUE :SAP
> #XB5DFFBDC :TYPE (* (STRUCT SB-VM::OS-CONTEXT-T-STRUCT))> (14))
> ?4: (SB-KERNEL::UNBOUND-SYMBOL-ERROR-HANDLER #<unavailable argument>
> #.(SB-SYS:INT-SAP #XB5DFFEF0) #<SB-ALIEN-INTERNALS:ALIEN-VALUE :SAP
> #XB5DFFBDC :TYPE (* (STRUCT SB-VM::OS-CONTEXT-T-STRUCT))> (14))[:EX..
> ?5: (SB-KERNEL:INTERNAL-ERROR #.(SB-SYS:INT-SAP #XB5DFFBDC)
> #<unavailable argument>)
> ?6: ("foreign function: #x806480C")
> ?7: ("foreign function: #x8052BCC")
> ?8: ("foreign function: #x8056BD3")
> ?9: (HUNCHENTOOT:LOG-MESSAGE :ERROR "Error while creating worker thread
> for new incoming connection: ~A")[:EXTERNAL]
> ?10: ((SB-PCL::FAST-METHOD HUNCHENTOOT:HANDLE-INCOMING-CONNECTION
> (HUNCHENTOOT:ONE-THREAD-PER-CONNECTION-TASKMASTER T)) ..)
> ?11: ((SB-PCL::FAST-METHOD HUNCHENTOOT:ACCEPT-CONNECTIONS
> (HUNCHENTOOT:ACCEPTOR)) #<unavailable argument> #<unavailable argument>
> #<HUNCHENTOOT:ACCEPTOR (host *, port 8000)>)
> ?12: ((FLET SB-THREAD::WITH-MUTEX-THUNK))
> ?13: ((FLET #:WITHOUT-INTERRUPTS-BODY-[CALL-WITH-MUTEX]477))
> ?14: (SB-THREAD::CALL-WITH-MUTEX ..)
> ?15: ((LAMBDA ()))
> ?16: ("foreign function: #x806480C")
> ?17: ("foreign function: #x8052C21")
> ?18: ("foreign function: #x805BD9D")
> ?19: ("foreign function: #xB7FB84C0")
>
> I found that not attempting to log a message solved this remaining problem.
>
> Thank you very much for your help!
>
> /Peter
>
>>
>> 2009/7/6 Peter Stiernstr?m <peter.stiernstrom at blixtvik.se>:
>> Hans,
>>
>> I should have realised I was editing the lispworks implementation myself
>> had I only had a cup of coffee this morning :-P
>>
>> Now when I tried your patch out I still get hangups but this is another
>> kind of hangup:
>>
>> debugger invoked on a UNBOUND-VARIABLE in thread #<THREAD "Hunchentoot
>> listener (*:8000)" RUNNING {AD467D1}>:
>> ?The variable HUNCHENTOOT:*ACCEPTOR* is unbound.
>>
>> I am trying this out with the hunchentoot default page by the way.
>>
>> /Peter
>>
>> Hans H?bner wrote:
>>>>> Peter,
>>>>>
>>>>> sorry, I am not able to reproduce the problem myself, so I made the
>>>>> patch blindly and made a mistake, working on the Lispworks code rather
>>>>> than the portable code that affects you. ?Please look at the first
>>>>> hunk of this diff:
>>>>>
>>>>> http://bknr.net/trac/changeset/4430?format=diff&new=4430
>>>>>
>>>>> and let me know if that does it for you.
>>>>>
>>>>> Sorry,
>>>>> Hans
>>>>>
>>>>> On Mon, Jul 6, 2009 at 11:09, Peter
>>>>> Stiernstr?m<peter.stiernstrom at blixtvik.se> wrote:
>>>>> Hi Hans,
>>>>>
>>>>> Hans H?bner wrote:
>>>>>>>> Hi Peter,
>>>>>>>>
>>>>>>>> 2009/7/6 Peter Stiernstr?m <peter.stiernstrom at blixtvik.se>
>>>>>>>>> I had a quick peek at client-as-string and it does indeed not handle the
>>>>>>>>> sb-bsd-sockets:not-connected-error and if I put a handler-case around
>>>>>>>>> body of client-as-string returning nil when the exception appears I can
>>>>>>>>> not reproduce my problem anymore.
>>>>>>>>>
>>>>>>>>> This wouldn't provide a portable solution though :-P
>>>>>>>> This really is a bug that requires fixing in usocket. ?There are
>>>>>>>> multiple issues:
>>>>>>>>
>>>>>>>> - As shown in the backtrace, the problem is that the getpeername()
>>>>>>>> call fails for a socket that is not connected anymore. ?SBCL does the
>>>>>>>> right thing by signalling a condition. ?Other implementations (I
>>>>>>>> checked CCL) seem to behave differently, i.e. return NIL in such a
>>>>>>>> case.
>>>>>>>>
>>>>>>>> - Usocket does not unify the behavior, so the implementation specific
>>>>>>>> condition percolates to the caller, Hunchentoot in this case.
>>>>>>>>
>>>>>>>> - Hunchentoot is not prepared to handle conditions when creating a new
>>>>>>>> worker thread. ?The call to CLIENT-AS-STRING is made when creating the
>>>>>>>> name for the handler process of a new incoming connection, and that is
>>>>>>>> done in the context of the server thread. ?Therefore, the signalled
>>>>>>>> condition will stop the acceptor process.
>>>>>>>>
>>>>>>>> I spent some thoughts on how a "portable solution" would look like,
>>>>>>>> but given that the Lisp implementations vary greatly in behavior,
>>>>>>>> fixing usocket would be a pretty large task that I don't have the time
>>>>>>>> to do right now. ?Thus, I would propose this patch:
>>>>>>>>
>>>>>>>> http://bknr.net/trac/changeset/4428?format=diff&new=4428
>>>>>>>>
>>>>>>>> It handles all conditions that are signaled during worker process
>>>>>>>> creation, under the theory that we want to prevent the acceptor
>>>>>>>> process from crashing under all circumstances. ?This is not a clean
>>>>>>>> solution in that it may paper over bugs, but given the limited number
>>>>>>>> of function invocations that are surrounded by a HANDLER-CASE, I'd say
>>>>>>>> that this is a proper intermediate fix.
>>>>>>>>
>>>>>>>> Please give it a try and let me know if it solves the problem for you.
>>>>> I tried your suggested patch but I can't seem to be able to get it to
>>>>> catch the exception for me. Were you able to duplicate the error
>>>>> yourself to verify that the suggested patch does indeed work? Since I am
>>>>> using the 1.0.0 hunchentoot release I couldn't just apply your patch but
>>>>> added the handler-case by hand and thus ended up with this in
>>>>> taskmaster.lisp:
>>>>>
>>>>> (defmethod handle-incoming-connection ((taskmaster
>>>>> one-thread-per-connection-taskmaster) handle)
>>>>> ?(incf *worker-counter*)
>>>>> ?;; check if we need to perform a global GC
>>>>> ?(when (and *cleanup-interval*
>>>>> ? ? ? ? ? ? (zerop (mod *worker-counter* *cleanup-interval*)))
>>>>> ? ?(when *cleanup-function*
>>>>> ? ? ?(funcall *cleanup-function*)))
>>>>> ?(handler-case
>>>>> ? ? ?(mp:process-run-function (format nil "Hunchentoot worker \(client:
>>>>> ~{~A:~A~})"
>>>>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? (multiple-value-list
>>>>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?(get-peer-address-and-port handle)))
>>>>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? nil #'process-connection
>>>>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? (taskmaster-acceptor taskmaster) handle)
>>>>> ? ?(error (cond)
>>>>> ? ? ?(log-message *lisp-errors-log-level*
>>>>> ? ? ? ? ? ? ? ? ? "Error while creating worker thread for new incoming
>>>>> connection: ~A" cond))))
>>>>>
>>>>> /Peter
>>>>>
>>>>>
>>>>>>>> -Hans
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> tbnl-devel site list
>>>>>>>> tbnl-devel at common-lisp.net
>>>>>>>> http://common-lisp.net/mailman/listinfo/tbnl-devel
>> _______________________________________________
>> tbnl-devel site list
>> tbnl-devel at common-lisp.net
>> http://common-lisp.net/mailman/listinfo/tbnl-devel
>>>>> _______________________________________________
>>>>> tbnl-devel site list
>>>>> tbnl-devel at common-lisp.net
>>>>> http://common-lisp.net/mailman/listinfo/tbnl-devel
>>>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>>>
>
>> _______________________________________________
>> tbnl-devel site list
>> tbnl-devel at common-lisp.net
>> http://common-lisp.net/mailman/listinfo/tbnl-devel
>
> - --
> Med v?nlig h?lsning,
>
> Peter Stiernstr?m
> 0708-810932
> Blixtvik AB
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkpR3kcACgkQ0brSZD05ZzDxywCdFzn0tdVZb35stsaCZL4uPSw5
> N5wAn1FC1VTcJyNV+c+bzIpLFfTAyMfW
> =k68p
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>



From peter.stiernstrom at blixtvik.se  Mon Jul  6 11:53:54 2009
From: peter.stiernstrom at blixtvik.se (=?ISO-8859-1?Q?Peter_Stiernstr=F6m?=)
Date: Mon, 06 Jul 2009 13:53:54 +0200
Subject: [hunchentoot-devel] Hunchentoot effective DOS-attack
In-Reply-To: <fd2982320907060422t588362cbsa09039a6afd62b8@mail.gmail.com>
References: <4A4DE786.90702@blixtvik.se>	<fd2982320907051439w6bd92e6bu516a66b2cb02619c@mail.gmail.com>
	<4A51A645.3000909@blixtvik.se>	<fd2982320907060135l1eb0fa5dx32e2daf115197c6c@mail.gmail.com>
	<4A51BF44.8080209@blixtvik.se>	<fd2982320907060215t542cd599m3f3207e99e520d8a@mail.gmail.com>
	<4A51D75F.5090303@blixtvik.se>	<fd2982320907060356ib6cb484ie4da6a686f18cb7d@mail.gmail.com>
	<4A51DE47.2040301@blixtvik.se>
	<fd2982320907060422t588362cbsa09039a6afd62b8@mail.gmail.com>
Message-ID: <4A51E5D2.5050207@blixtvik.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hans H?bner wrote:

> Peter,
> 
> try this:
> 
> http://bknr.net/trac/changeset/4434?format=diff&new=4434

Hello Hans,

I still get an unbound-variable condition for hunchentoot:*acceptor* but
the trace look a bit different:

The variable HUNCHENTOOT:*ACCEPTOR* is unbound.
BREAK was entered because of *BREAK-ON-SIGNALS* (now rebound to NIL).
   [Condition of type SIMPLE-CONDITION]

Restarts:
 0: [CONTINUE] Return from BREAK.
 1: [REASSIGN] Return from BREAK and assign a new value to
*BREAK-ON-SIGNALS*.
 2: [TERMINATE-THREAD] Terminate this thread (#<THREAD "Hunchentoot
worker (client: 127.0.0.1:46427)" RUNNING {AF2EA11}>)

Backtrace:
  0: (BREAK "~A~%BREAK was entered because of *BREAK-ON-SIGNALS* ~\n
                (now rebound to NIL)." #<UNBOUND-VARIABLE *ACCEPTOR*
{AF30361}>)
  1: (SIGNAL #<UNBOUND-VARIABLE *ACCEPTOR* {AF30361}>)[:EXTERNAL]
  2: (ERROR UNBOUND-VARIABLE)[:EXTERNAL]
  3: (SB-KERNEL::UNBOUND-SYMBOL-ERROR-HANDLER #<unavailable argument>
#.(SB-SYS:INT-SAP #XB5724028) #<SB-ALIEN-INTERNALS:ALIEN-VALUE :SAP
#XB5723CDC :TYPE (* (STRUCT SB-VM::OS-CONTEXT-T-STRUCT))> (14))
  4: (SB-KERNEL::UNBOUND-SYMBOL-ERROR-HANDLER #<unavailable argument>
#.(SB-SYS:INT-SAP #XB5724028) #<SB-ALIEN-INTERNALS:ALIEN-VALUE :SAP
#XB5723CDC :TYPE (* (STRUCT SB-VM::OS-CONTEXT-T-STRUCT))> (14))[:EX..
  5: (SB-KERNEL:INTERNAL-ERROR #.(SB-SYS:INT-SAP #XB5723CDC)
#<unavailable argument>)
  6: ("foreign function: #x806480C")
  7: ("foreign function: #x8052BCC")
  8: ("foreign function: #x8056BD3")
  9: ((LAMBDA ()))
 10: ((FLET SB-THREAD::WITH-MUTEX-THUNK))
 11: ((FLET #:WITHOUT-INTERRUPTS-BODY-[CALL-WITH-MUTEX]477))
 12: (SB-THREAD::CALL-WITH-MUTEX ..)
 13: ((LAMBDA ()))
 14: ("foreign function: #x806480C")
 15: ("foreign function: #x8052C21")
 16: ("foreign function: #x805BD9D")
 17: ("foreign function: #xB7FB84C0")


I did set *break-on-signals* to 'unbound-variable and my modified
function now looks like this:

(defmethod handle-incoming-connection ((taskmaster
one-thread-per-connection-taskmaster) socket)
  (let ((*acceptor* (taskmaster-acceptor taskmaster)))
    (handler-case
        (bt:make-thread (lambda ()
                          (process-connection *acceptor* socket))
                        :name (format nil "Hunchentoot worker \(client:
~A)" (client-as-string socket)))
      (error (e)
        (log-message *lisp-errors-log-level*
                     "Error while creating worker thread for new
incoming connection: ~A" e)))))

/Peter

> 
> -Hans
> 
> On Mon, Jul 6, 2009 at 13:21, Peter
> Stiernstr?m<peter.stiernstrom at blixtvik.se> wrote:
> Hello Hans,
> 
> Hans H?bner wrote:
>>>> Peter, as I cannot reproduce the problem myself, can you please post a
>>>> stack backtrace?  Thanks!
> The variable HUNCHENTOOT:*ACCEPTOR* is unbound.
> BREAK was entered because of *BREAK-ON-SIGNALS* (now rebound to NIL).
>   [Condition of type SIMPLE-CONDITION]
> 
> Restarts:
>  0: [CONTINUE] Return from BREAK.
>  1: [REASSIGN] Return from BREAK and assign a new value to
> *BREAK-ON-SIGNALS*.
>  2: [TERMINATE-THREAD] Terminate this thread (#<THREAD "Hunchentoot
> listener (*:8000)" RUNNING {C42AAE9}>)
> 
> Backtrace:
>  0: (BREAK "~A~%BREAK was entered because of *BREAK-ON-SIGNALS* ~\n
>                (now rebound to NIL)." #<UNBOUND-VARIABLE *ACCEPTOR*
> {AD37FC1}>)
>  1: (SIGNAL #<UNBOUND-VARIABLE *ACCEPTOR* {AD37FC1}>)[:EXTERNAL]
>  2: (ERROR UNBOUND-VARIABLE)[:EXTERNAL]
>  3: (SB-KERNEL::UNBOUND-SYMBOL-ERROR-HANDLER #<unavailable argument>
> #.(SB-SYS:INT-SAP #XB5DFFEF0) #<SB-ALIEN-INTERNALS:ALIEN-VALUE :SAP
> #XB5DFFBDC :TYPE (* (STRUCT SB-VM::OS-CONTEXT-T-STRUCT))> (14))
>  4: (SB-KERNEL::UNBOUND-SYMBOL-ERROR-HANDLER #<unavailable argument>
> #.(SB-SYS:INT-SAP #XB5DFFEF0) #<SB-ALIEN-INTERNALS:ALIEN-VALUE :SAP
> #XB5DFFBDC :TYPE (* (STRUCT SB-VM::OS-CONTEXT-T-STRUCT))> (14))[:EX..
>  5: (SB-KERNEL:INTERNAL-ERROR #.(SB-SYS:INT-SAP #XB5DFFBDC)
> #<unavailable argument>)
>  6: ("foreign function: #x806480C")
>  7: ("foreign function: #x8052BCC")
>  8: ("foreign function: #x8056BD3")
>  9: (HUNCHENTOOT:LOG-MESSAGE :ERROR "Error while creating worker thread
> for new incoming connection: ~A")[:EXTERNAL]
>  10: ((SB-PCL::FAST-METHOD HUNCHENTOOT:HANDLE-INCOMING-CONNECTION
> (HUNCHENTOOT:ONE-THREAD-PER-CONNECTION-TASKMASTER T)) ..)
>  11: ((SB-PCL::FAST-METHOD HUNCHENTOOT:ACCEPT-CONNECTIONS
> (HUNCHENTOOT:ACCEPTOR)) #<unavailable argument> #<unavailable argument>
> #<HUNCHENTOOT:ACCEPTOR (host *, port 8000)>)
>  12: ((FLET SB-THREAD::WITH-MUTEX-THUNK))
>  13: ((FLET #:WITHOUT-INTERRUPTS-BODY-[CALL-WITH-MUTEX]477))
>  14: (SB-THREAD::CALL-WITH-MUTEX ..)
>  15: ((LAMBDA ()))
>  16: ("foreign function: #x806480C")
>  17: ("foreign function: #x8052C21")
>  18: ("foreign function: #x805BD9D")
>  19: ("foreign function: #xB7FB84C0")
> 
> I found that not attempting to log a message solved this remaining problem.
> 
> Thank you very much for your help!
> 
> /Peter
> 
>>>> 2009/7/6 Peter Stiernstr?m <peter.stiernstrom at blixtvik.se>:
>>>> Hans,
>>>>
>>>> I should have realised I was editing the lispworks implementation myself
>>>> had I only had a cup of coffee this morning :-P
>>>>
>>>> Now when I tried your patch out I still get hangups but this is another
>>>> kind of hangup:
>>>>
>>>> debugger invoked on a UNBOUND-VARIABLE in thread #<THREAD "Hunchentoot
>>>> listener (*:8000)" RUNNING {AD467D1}>:
>>>>  The variable HUNCHENTOOT:*ACCEPTOR* is unbound.
>>>>
>>>> I am trying this out with the hunchentoot default page by the way.
>>>>
>>>> /Peter
>>>>
>>>> Hans H?bner wrote:
>>>>>>> Peter,
>>>>>>>
>>>>>>> sorry, I am not able to reproduce the problem myself, so I made the
>>>>>>> patch blindly and made a mistake, working on the Lispworks code rather
>>>>>>> than the portable code that affects you.  Please look at the first
>>>>>>> hunk of this diff:
>>>>>>>
>>>>>>> http://bknr.net/trac/changeset/4430?format=diff&new=4430
>>>>>>>
>>>>>>> and let me know if that does it for you.
>>>>>>>
>>>>>>> Sorry,
>>>>>>> Hans
>>>>>>>
>>>>>>> On Mon, Jul 6, 2009 at 11:09, Peter
>>>>>>> Stiernstr?m<peter.stiernstrom at blixtvik.se> wrote:
>>>>>>> Hi Hans,
>>>>>>>
>>>>>>> Hans H?bner wrote:
>>>>>>>>>> Hi Peter,
>>>>>>>>>>
>>>>>>>>>> 2009/7/6 Peter Stiernstr?m <peter.stiernstrom at blixtvik.se>
>>>>>>>>>>> I had a quick peek at client-as-string and it does indeed not handle the
>>>>>>>>>>> sb-bsd-sockets:not-connected-error and if I put a handler-case around
>>>>>>>>>>> body of client-as-string returning nil when the exception appears I can
>>>>>>>>>>> not reproduce my problem anymore.
>>>>>>>>>>>
>>>>>>>>>>> This wouldn't provide a portable solution though :-P
>>>>>>>>>> This really is a bug that requires fixing in usocket.  There are
>>>>>>>>>> multiple issues:
>>>>>>>>>>
>>>>>>>>>> - As shown in the backtrace, the problem is that the getpeername()
>>>>>>>>>> call fails for a socket that is not connected anymore.  SBCL does the
>>>>>>>>>> right thing by signalling a condition.  Other implementations (I
>>>>>>>>>> checked CCL) seem to behave differently, i.e. return NIL in such a
>>>>>>>>>> case.
>>>>>>>>>>
>>>>>>>>>> - Usocket does not unify the behavior, so the implementation specific
>>>>>>>>>> condition percolates to the caller, Hunchentoot in this case.
>>>>>>>>>>
>>>>>>>>>> - Hunchentoot is not prepared to handle conditions when creating a new
>>>>>>>>>> worker thread.  The call to CLIENT-AS-STRING is made when creating the
>>>>>>>>>> name for the handler process of a new incoming connection, and that is
>>>>>>>>>> done in the context of the server thread.  Therefore, the signalled
>>>>>>>>>> condition will stop the acceptor process.
>>>>>>>>>>
>>>>>>>>>> I spent some thoughts on how a "portable solution" would look like,
>>>>>>>>>> but given that the Lisp implementations vary greatly in behavior,
>>>>>>>>>> fixing usocket would be a pretty large task that I don't have the time
>>>>>>>>>> to do right now.  Thus, I would propose this patch:
>>>>>>>>>>
>>>>>>>>>> http://bknr.net/trac/changeset/4428?format=diff&new=4428
>>>>>>>>>>
>>>>>>>>>> It handles all conditions that are signaled during worker process
>>>>>>>>>> creation, under the theory that we want to prevent the acceptor
>>>>>>>>>> process from crashing under all circumstances.  This is not a clean
>>>>>>>>>> solution in that it may paper over bugs, but given the limited number
>>>>>>>>>> of function invocations that are surrounded by a HANDLER-CASE, I'd say
>>>>>>>>>> that this is a proper intermediate fix.
>>>>>>>>>>
>>>>>>>>>> Please give it a try and let me know if it solves the problem for you.
>>>>>>> I tried your suggested patch but I can't seem to be able to get it to
>>>>>>> catch the exception for me. Were you able to duplicate the error
>>>>>>> yourself to verify that the suggested patch does indeed work? Since I am
>>>>>>> using the 1.0.0 hunchentoot release I couldn't just apply your patch but
>>>>>>> added the handler-case by hand and thus ended up with this in
>>>>>>> taskmaster.lisp:
>>>>>>>
>>>>>>> (defmethod handle-incoming-connection ((taskmaster
>>>>>>> one-thread-per-connection-taskmaster) handle)
>>>>>>>  (incf *worker-counter*)
>>>>>>>  ;; check if we need to perform a global GC
>>>>>>>  (when (and *cleanup-interval*
>>>>>>>             (zerop (mod *worker-counter* *cleanup-interval*)))
>>>>>>>    (when *cleanup-function*
>>>>>>>      (funcall *cleanup-function*)))
>>>>>>>  (handler-case
>>>>>>>      (mp:process-run-function (format nil "Hunchentoot worker \(client:
>>>>>>> ~{~A:~A~})"
>>>>>>>                                       (multiple-value-list
>>>>>>>                                        (get-peer-address-and-port handle)))
>>>>>>>                               nil #'process-connection
>>>>>>>                               (taskmaster-acceptor taskmaster) handle)
>>>>>>>    (error (cond)
>>>>>>>      (log-message *lisp-errors-log-level*
>>>>>>>                   "Error while creating worker thread for new incoming
>>>>>>> connection: ~A" cond))))
>>>>>>>
>>>>>>> /Peter
>>>>>>>
>>>>>>>
>>>>>>>>>> -Hans
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> tbnl-devel site list
>>>>>>>>>> tbnl-devel at common-lisp.net
>>>>>>>>>> http://common-lisp.net/mailman/listinfo/tbnl-devel
>>>> _______________________________________________
>>>> tbnl-devel site list
>>>> tbnl-devel at common-lisp.net
>>>> http://common-lisp.net/mailman/listinfo/tbnl-devel
>>>>>>> _______________________________________________
>>>>>>> tbnl-devel site list
>>>>>>> tbnl-devel at common-lisp.net
>>>>>>> http://common-lisp.net/mailman/listinfo/tbnl-devel
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>>>> _______________________________________________
>>>> tbnl-devel site list
>>>> tbnl-devel at common-lisp.net
>>>> http://common-lisp.net/mailman/listinfo/tbnl-devel
>>
_______________________________________________
tbnl-devel site list
tbnl-devel at common-lisp.net
http://common-lisp.net/mailman/listinfo/tbnl-devel
>>

> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel

- --
Med v?nlig h?lsning,

Peter Stiernstr?m
0708-810932
Blixtvik AB
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkpR5dIACgkQ0brSZD05ZzDvbwCgmnIIeWo0dNZZs/tDzUO6cCqD
UQAAoKedq3OpsV9ru6BK0DINB5SCBpya
=PEA/
-----END PGP SIGNATURE-----



From hans.huebner at gmail.com  Mon Jul  6 11:59:29 2009
From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Mon, 6 Jul 2009 13:59:29 +0200
Subject: [hunchentoot-devel] Hunchentoot effective DOS-attack
In-Reply-To: <4A51E5D2.5050207@blixtvik.se>
References: <4A4DE786.90702@blixtvik.se> <4A51A645.3000909@blixtvik.se> 
	<fd2982320907060135l1eb0fa5dx32e2daf115197c6c@mail.gmail.com> 
	<4A51BF44.8080209@blixtvik.se>
	<fd2982320907060215t542cd599m3f3207e99e520d8a@mail.gmail.com> 
	<4A51D75F.5090303@blixtvik.se>
	<fd2982320907060356ib6cb484ie4da6a686f18cb7d@mail.gmail.com> 
	<4A51DE47.2040301@blixtvik.se>
	<fd2982320907060422t588362cbsa09039a6afd62b8@mail.gmail.com> 
	<4A51E5D2.5050207@blixtvik.se>
Message-ID: <fd2982320907060459i228af305xc1526bdd3e89c874@mail.gmail.com>

Oh well, *ACCEPTOR* was not inherited by the new process, so use this:

http://bknr.net/trac/changeset/4435?format=diff&new=4435

-Hans

On Mon, Jul 6, 2009 at 13:53, Peter
Stiernstr?m<peter.stiernstrom at blixtvik.se> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hans H?bner wrote:
>
>> Peter,
>>
>> try this:
>>
>> http://bknr.net/trac/changeset/4434?format=diff&new=4434
>
> Hello Hans,
>
> I still get an unbound-variable condition for hunchentoot:*acceptor* but
> the trace look a bit different:
>
> The variable HUNCHENTOOT:*ACCEPTOR* is unbound.
> BREAK was entered because of *BREAK-ON-SIGNALS* (now rebound to NIL).
> ? [Condition of type SIMPLE-CONDITION]
>
> Restarts:
> ?0: [CONTINUE] Return from BREAK.
> ?1: [REASSIGN] Return from BREAK and assign a new value to
> *BREAK-ON-SIGNALS*.
> ?2: [TERMINATE-THREAD] Terminate this thread (#<THREAD "Hunchentoot
> worker (client: 127.0.0.1:46427)" RUNNING {AF2EA11}>)
>
> Backtrace:
> ?0: (BREAK "~A~%BREAK was entered because of *BREAK-ON-SIGNALS* ~\n
> ? ? ? ? ? ? ? ?(now rebound to NIL)." #<UNBOUND-VARIABLE *ACCEPTOR*
> {AF30361}>)
> ?1: (SIGNAL #<UNBOUND-VARIABLE *ACCEPTOR* {AF30361}>)[:EXTERNAL]
> ?2: (ERROR UNBOUND-VARIABLE)[:EXTERNAL]
> ?3: (SB-KERNEL::UNBOUND-SYMBOL-ERROR-HANDLER #<unavailable argument>
> #.(SB-SYS:INT-SAP #XB5724028) #<SB-ALIEN-INTERNALS:ALIEN-VALUE :SAP
> #XB5723CDC :TYPE (* (STRUCT SB-VM::OS-CONTEXT-T-STRUCT))> (14))
> ?4: (SB-KERNEL::UNBOUND-SYMBOL-ERROR-HANDLER #<unavailable argument>
> #.(SB-SYS:INT-SAP #XB5724028) #<SB-ALIEN-INTERNALS:ALIEN-VALUE :SAP
> #XB5723CDC :TYPE (* (STRUCT SB-VM::OS-CONTEXT-T-STRUCT))> (14))[:EX..
> ?5: (SB-KERNEL:INTERNAL-ERROR #.(SB-SYS:INT-SAP #XB5723CDC)
> #<unavailable argument>)
> ?6: ("foreign function: #x806480C")
> ?7: ("foreign function: #x8052BCC")
> ?8: ("foreign function: #x8056BD3")
> ?9: ((LAMBDA ()))
> ?10: ((FLET SB-THREAD::WITH-MUTEX-THUNK))
> ?11: ((FLET #:WITHOUT-INTERRUPTS-BODY-[CALL-WITH-MUTEX]477))
> ?12: (SB-THREAD::CALL-WITH-MUTEX ..)
> ?13: ((LAMBDA ()))
> ?14: ("foreign function: #x806480C")
> ?15: ("foreign function: #x8052C21")
> ?16: ("foreign function: #x805BD9D")
> ?17: ("foreign function: #xB7FB84C0")
>
>
> I did set *break-on-signals* to 'unbound-variable and my modified
> function now looks like this:
>
> (defmethod handle-incoming-connection ((taskmaster
> one-thread-per-connection-taskmaster) socket)
> ?(let ((*acceptor* (taskmaster-acceptor taskmaster)))
> ? ?(handler-case
> ? ? ? ?(bt:make-thread (lambda ()
> ? ? ? ? ? ? ? ? ? ? ? ? ?(process-connection *acceptor* socket))
> ? ? ? ? ? ? ? ? ? ? ? ?:name (format nil "Hunchentoot worker \(client:
> ~A)" (client-as-string socket)))
> ? ? ?(error (e)
> ? ? ? ?(log-message *lisp-errors-log-level*
> ? ? ? ? ? ? ? ? ? ? "Error while creating worker thread for new
> incoming connection: ~A" e)))))
>
> /Peter
>
>>
>> -Hans
>>
>> On Mon, Jul 6, 2009 at 13:21, Peter
>> Stiernstr?m<peter.stiernstrom at blixtvik.se> wrote:
>> Hello Hans,
>>
>> Hans H?bner wrote:
>>>>> Peter, as I cannot reproduce the problem myself, can you please post a
>>>>> stack backtrace? ?Thanks!
>> The variable HUNCHENTOOT:*ACCEPTOR* is unbound.
>> BREAK was entered because of *BREAK-ON-SIGNALS* (now rebound to NIL).
>> ? [Condition of type SIMPLE-CONDITION]
>>
>> Restarts:
>> ?0: [CONTINUE] Return from BREAK.
>> ?1: [REASSIGN] Return from BREAK and assign a new value to
>> *BREAK-ON-SIGNALS*.
>> ?2: [TERMINATE-THREAD] Terminate this thread (#<THREAD "Hunchentoot
>> listener (*:8000)" RUNNING {C42AAE9}>)
>>
>> Backtrace:
>> ?0: (BREAK "~A~%BREAK was entered because of *BREAK-ON-SIGNALS* ~\n
>> ? ? ? ? ? ? ? ?(now rebound to NIL)." #<UNBOUND-VARIABLE *ACCEPTOR*
>> {AD37FC1}>)
>> ?1: (SIGNAL #<UNBOUND-VARIABLE *ACCEPTOR* {AD37FC1}>)[:EXTERNAL]
>> ?2: (ERROR UNBOUND-VARIABLE)[:EXTERNAL]
>> ?3: (SB-KERNEL::UNBOUND-SYMBOL-ERROR-HANDLER #<unavailable argument>
>> #.(SB-SYS:INT-SAP #XB5DFFEF0) #<SB-ALIEN-INTERNALS:ALIEN-VALUE :SAP
>> #XB5DFFBDC :TYPE (* (STRUCT SB-VM::OS-CONTEXT-T-STRUCT))> (14))
>> ?4: (SB-KERNEL::UNBOUND-SYMBOL-ERROR-HANDLER #<unavailable argument>
>> #.(SB-SYS:INT-SAP #XB5DFFEF0) #<SB-ALIEN-INTERNALS:ALIEN-VALUE :SAP
>> #XB5DFFBDC :TYPE (* (STRUCT SB-VM::OS-CONTEXT-T-STRUCT))> (14))[:EX..
>> ?5: (SB-KERNEL:INTERNAL-ERROR #.(SB-SYS:INT-SAP #XB5DFFBDC)
>> #<unavailable argument>)
>> ?6: ("foreign function: #x806480C")
>> ?7: ("foreign function: #x8052BCC")
>> ?8: ("foreign function: #x8056BD3")
>> ?9: (HUNCHENTOOT:LOG-MESSAGE :ERROR "Error while creating worker thread
>> for new incoming connection: ~A")[:EXTERNAL]
>> ?10: ((SB-PCL::FAST-METHOD HUNCHENTOOT:HANDLE-INCOMING-CONNECTION
>> (HUNCHENTOOT:ONE-THREAD-PER-CONNECTION-TASKMASTER T)) ..)
>> ?11: ((SB-PCL::FAST-METHOD HUNCHENTOOT:ACCEPT-CONNECTIONS
>> (HUNCHENTOOT:ACCEPTOR)) #<unavailable argument> #<unavailable argument>
>> #<HUNCHENTOOT:ACCEPTOR (host *, port 8000)>)
>> ?12: ((FLET SB-THREAD::WITH-MUTEX-THUNK))
>> ?13: ((FLET #:WITHOUT-INTERRUPTS-BODY-[CALL-WITH-MUTEX]477))
>> ?14: (SB-THREAD::CALL-WITH-MUTEX ..)
>> ?15: ((LAMBDA ()))
>> ?16: ("foreign function: #x806480C")
>> ?17: ("foreign function: #x8052C21")
>> ?18: ("foreign function: #x805BD9D")
>> ?19: ("foreign function: #xB7FB84C0")
>>
>> I found that not attempting to log a message solved this remaining problem.
>>
>> Thank you very much for your help!
>>
>> /Peter
>>
>>>>> 2009/7/6 Peter Stiernstr?m <peter.stiernstrom at blixtvik.se>:
>>>>> Hans,
>>>>>
>>>>> I should have realised I was editing the lispworks implementation myself
>>>>> had I only had a cup of coffee this morning :-P
>>>>>
>>>>> Now when I tried your patch out I still get hangups but this is another
>>>>> kind of hangup:
>>>>>
>>>>> debugger invoked on a UNBOUND-VARIABLE in thread #<THREAD "Hunchentoot
>>>>> listener (*:8000)" RUNNING {AD467D1}>:
>>>>> ?The variable HUNCHENTOOT:*ACCEPTOR* is unbound.
>>>>>
>>>>> I am trying this out with the hunchentoot default page by the way.
>>>>>
>>>>> /Peter
>>>>>
>>>>> Hans H?bner wrote:
>>>>>>>> Peter,
>>>>>>>>
>>>>>>>> sorry, I am not able to reproduce the problem myself, so I made the
>>>>>>>> patch blindly and made a mistake, working on the Lispworks code rather
>>>>>>>> than the portable code that affects you. ?Please look at the first
>>>>>>>> hunk of this diff:
>>>>>>>>
>>>>>>>> http://bknr.net/trac/changeset/4430?format=diff&new=4430
>>>>>>>>
>>>>>>>> and let me know if that does it for you.
>>>>>>>>
>>>>>>>> Sorry,
>>>>>>>> Hans
>>>>>>>>
>>>>>>>> On Mon, Jul 6, 2009 at 11:09, Peter
>>>>>>>> Stiernstr?m<peter.stiernstrom at blixtvik.se> wrote:
>>>>>>>> Hi Hans,
>>>>>>>>
>>>>>>>> Hans H?bner wrote:
>>>>>>>>>>> Hi Peter,
>>>>>>>>>>>
>>>>>>>>>>> 2009/7/6 Peter Stiernstr?m <peter.stiernstrom at blixtvik.se>
>>>>>>>>>>>> I had a quick peek at client-as-string and it does indeed not handle the
>>>>>>>>>>>> sb-bsd-sockets:not-connected-error and if I put a handler-case around
>>>>>>>>>>>> body of client-as-string returning nil when the exception appears I can
>>>>>>>>>>>> not reproduce my problem anymore.
>>>>>>>>>>>>
>>>>>>>>>>>> This wouldn't provide a portable solution though :-P
>>>>>>>>>>> This really is a bug that requires fixing in usocket. ?There are
>>>>>>>>>>> multiple issues:
>>>>>>>>>>>
>>>>>>>>>>> - As shown in the backtrace, the problem is that the getpeername()
>>>>>>>>>>> call fails for a socket that is not connected anymore. ?SBCL does the
>>>>>>>>>>> right thing by signalling a condition. ?Other implementations (I
>>>>>>>>>>> checked CCL) seem to behave differently, i.e. return NIL in such a
>>>>>>>>>>> case.
>>>>>>>>>>>
>>>>>>>>>>> - Usocket does not unify the behavior, so the implementation specific
>>>>>>>>>>> condition percolates to the caller, Hunchentoot in this case.
>>>>>>>>>>>
>>>>>>>>>>> - Hunchentoot is not prepared to handle conditions when creating a new
>>>>>>>>>>> worker thread. ?The call to CLIENT-AS-STRING is made when creating the
>>>>>>>>>>> name for the handler process of a new incoming connection, and that is
>>>>>>>>>>> done in the context of the server thread. ?Therefore, the signalled
>>>>>>>>>>> condition will stop the acceptor process.
>>>>>>>>>>>
>>>>>>>>>>> I spent some thoughts on how a "portable solution" would look like,
>>>>>>>>>>> but given that the Lisp implementations vary greatly in behavior,
>>>>>>>>>>> fixing usocket would be a pretty large task that I don't have the time
>>>>>>>>>>> to do right now. ?Thus, I would propose this patch:
>>>>>>>>>>>
>>>>>>>>>>> http://bknr.net/trac/changeset/4428?format=diff&new=4428
>>>>>>>>>>>
>>>>>>>>>>> It handles all conditions that are signaled during worker process
>>>>>>>>>>> creation, under the theory that we want to prevent the acceptor
>>>>>>>>>>> process from crashing under all circumstances. ?This is not a clean
>>>>>>>>>>> solution in that it may paper over bugs, but given the limited number
>>>>>>>>>>> of function invocations that are surrounded by a HANDLER-CASE, I'd say
>>>>>>>>>>> that this is a proper intermediate fix.
>>>>>>>>>>>
>>>>>>>>>>> Please give it a try and let me know if it solves the problem for you.
>>>>>>>> I tried your suggested patch but I can't seem to be able to get it to
>>>>>>>> catch the exception for me. Were you able to duplicate the error
>>>>>>>> yourself to verify that the suggested patch does indeed work? Since I am
>>>>>>>> using the 1.0.0 hunchentoot release I couldn't just apply your patch but
>>>>>>>> added the handler-case by hand and thus ended up with this in
>>>>>>>> taskmaster.lisp:
>>>>>>>>
>>>>>>>> (defmethod handle-incoming-connection ((taskmaster
>>>>>>>> one-thread-per-connection-taskmaster) handle)
>>>>>>>> ?(incf *worker-counter*)
>>>>>>>> ?;; check if we need to perform a global GC
>>>>>>>> ?(when (and *cleanup-interval*
>>>>>>>> ? ? ? ? ? ? (zerop (mod *worker-counter* *cleanup-interval*)))
>>>>>>>> ? ?(when *cleanup-function*
>>>>>>>> ? ? ?(funcall *cleanup-function*)))
>>>>>>>> ?(handler-case
>>>>>>>> ? ? ?(mp:process-run-function (format nil "Hunchentoot worker \(client:
>>>>>>>> ~{~A:~A~})"
>>>>>>>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? (multiple-value-list
>>>>>>>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?(get-peer-address-and-port handle)))
>>>>>>>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? nil #'process-connection
>>>>>>>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? (taskmaster-acceptor taskmaster) handle)
>>>>>>>> ? ?(error (cond)
>>>>>>>> ? ? ?(log-message *lisp-errors-log-level*
>>>>>>>> ? ? ? ? ? ? ? ? ? "Error while creating worker thread for new incoming
>>>>>>>> connection: ~A" cond))))
>>>>>>>>
>>>>>>>> /Peter
>>>>>>>>
>>>>>>>>
>>>>>>>>>>> -Hans
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> tbnl-devel site list
>>>>>>>>>>> tbnl-devel at common-lisp.net
>>>>>>>>>>> http://common-lisp.net/mailman/listinfo/tbnl-devel
>>>>> _______________________________________________
>>>>> tbnl-devel site list
>>>>> tbnl-devel at common-lisp.net
>>>>> http://common-lisp.net/mailman/listinfo/tbnl-devel
>>>>>>>> _______________________________________________
>>>>>>>> tbnl-devel site list
>>>>>>>> tbnl-devel at common-lisp.net
>>>>>>>> http://common-lisp.net/mailman/listinfo/tbnl-devel
>> _______________________________________________
>> tbnl-devel site list
>> tbnl-devel at common-lisp.net
>> http://common-lisp.net/mailman/listinfo/tbnl-devel
>>>>> _______________________________________________
>>>>> tbnl-devel site list
>>>>> tbnl-devel at common-lisp.net
>>>>> http://common-lisp.net/mailman/listinfo/tbnl-devel
>>>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>>>
>
>> _______________________________________________
>> tbnl-devel site list
>> tbnl-devel at common-lisp.net
>> http://common-lisp.net/mailman/listinfo/tbnl-devel
>
> - --
> Med v?nlig h?lsning,
>
> Peter Stiernstr?m
> 0708-810932
> Blixtvik AB
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkpR5dIACgkQ0brSZD05ZzDvbwCgmnIIeWo0dNZZs/tDzUO6cCqD
> UQAAoKedq3OpsV9ru6BK0DINB5SCBpya
> =PEA/
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>



From peter.stiernstrom at blixtvik.se  Mon Jul  6 12:18:24 2009
From: peter.stiernstrom at blixtvik.se (=?ISO-8859-1?Q?Peter_Stiernstr=F6m?=)
Date: Mon, 06 Jul 2009 14:18:24 +0200
Subject: [hunchentoot-devel] Hunchentoot effective DOS-attack
In-Reply-To: <fd2982320907060459i228af305xc1526bdd3e89c874@mail.gmail.com>
References: <4A4DE786.90702@blixtvik.se> <4A51A645.3000909@blixtvik.se>
	<fd2982320907060135l1eb0fa5dx32e2daf115197c6c@mail.gmail.com>
	<4A51BF44.8080209@blixtvik.se>	<fd2982320907060215t542cd599m3f3207e99e520d8a@mail.gmail.com>
	<4A51D75F.5090303@blixtvik.se>	<fd2982320907060356ib6cb484ie4da6a686f18cb7d@mail.gmail.com>
	<4A51DE47.2040301@blixtvik.se>	<fd2982320907060422t588362cbsa09039a6afd62b8@mail.gmail.com>
	<4A51E5D2.5050207@blixtvik.se>
	<fd2982320907060459i228af305xc1526bdd3e89c874@mail.gmail.com>
Message-ID: <4A51EB90.20701@blixtvik.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hans H?bner wrote:
> Oh well, *ACCEPTOR* was not inherited by the new process, so use this:
> 
> http://bknr.net/trac/changeset/4435?format=diff&new=4435

That seems to fix the last issue I had! Thanks a lot for your time Hans.
Should one raise this issue to the attention of the usocket developers
though?

/Peter

> 
> -Hans
> 
> On Mon, Jul 6, 2009 at 13:53, Peter
> Stiernstr?m<peter.stiernstrom at blixtvik.se> wrote:
> Hans H?bner wrote:
> 
>>>> Peter,
>>>>
>>>> try this:
>>>>
>>>> http://bknr.net/trac/changeset/4434?format=diff&new=4434
> Hello Hans,
> 
> I still get an unbound-variable condition for hunchentoot:*acceptor* but
> the trace look a bit different:
> 
> The variable HUNCHENTOOT:*ACCEPTOR* is unbound.
> BREAK was entered because of *BREAK-ON-SIGNALS* (now rebound to NIL).
>   [Condition of type SIMPLE-CONDITION]
> 
> Restarts:
>  0: [CONTINUE] Return from BREAK.
>  1: [REASSIGN] Return from BREAK and assign a new value to
> *BREAK-ON-SIGNALS*.
>  2: [TERMINATE-THREAD] Terminate this thread (#<THREAD "Hunchentoot
> worker (client: 127.0.0.1:46427)" RUNNING {AF2EA11}>)
> 
> Backtrace:
>  0: (BREAK "~A~%BREAK was entered because of *BREAK-ON-SIGNALS* ~\n
>                (now rebound to NIL)." #<UNBOUND-VARIABLE *ACCEPTOR*
> {AF30361}>)
>  1: (SIGNAL #<UNBOUND-VARIABLE *ACCEPTOR* {AF30361}>)[:EXTERNAL]
>  2: (ERROR UNBOUND-VARIABLE)[:EXTERNAL]
>  3: (SB-KERNEL::UNBOUND-SYMBOL-ERROR-HANDLER #<unavailable argument>
> #.(SB-SYS:INT-SAP #XB5724028) #<SB-ALIEN-INTERNALS:ALIEN-VALUE :SAP
> #XB5723CDC :TYPE (* (STRUCT SB-VM::OS-CONTEXT-T-STRUCT))> (14))
>  4: (SB-KERNEL::UNBOUND-SYMBOL-ERROR-HANDLER #<unavailable argument>
> #.(SB-SYS:INT-SAP #XB5724028) #<SB-ALIEN-INTERNALS:ALIEN-VALUE :SAP
> #XB5723CDC :TYPE (* (STRUCT SB-VM::OS-CONTEXT-T-STRUCT))> (14))[:EX..
>  5: (SB-KERNEL:INTERNAL-ERROR #.(SB-SYS:INT-SAP #XB5723CDC)
> #<unavailable argument>)
>  6: ("foreign function: #x806480C")
>  7: ("foreign function: #x8052BCC")
>  8: ("foreign function: #x8056BD3")
>  9: ((LAMBDA ()))
>  10: ((FLET SB-THREAD::WITH-MUTEX-THUNK))
>  11: ((FLET #:WITHOUT-INTERRUPTS-BODY-[CALL-WITH-MUTEX]477))
>  12: (SB-THREAD::CALL-WITH-MUTEX ..)
>  13: ((LAMBDA ()))
>  14: ("foreign function: #x806480C")
>  15: ("foreign function: #x8052C21")
>  16: ("foreign function: #x805BD9D")
>  17: ("foreign function: #xB7FB84C0")
> 
> 
> I did set *break-on-signals* to 'unbound-variable and my modified
> function now looks like this:
> 
> (defmethod handle-incoming-connection ((taskmaster
> one-thread-per-connection-taskmaster) socket)
>  (let ((*acceptor* (taskmaster-acceptor taskmaster)))
>    (handler-case
>        (bt:make-thread (lambda ()
>                          (process-connection *acceptor* socket))
>                        :name (format nil "Hunchentoot worker \(client:
> ~A)" (client-as-string socket)))
>      (error (e)
>        (log-message *lisp-errors-log-level*
>                     "Error while creating worker thread for new
> incoming connection: ~A" e)))))
> 
> /Peter
> 
>>>> -Hans
>>>>
>>>> On Mon, Jul 6, 2009 at 13:21, Peter
>>>> Stiernstr?m<peter.stiernstrom at blixtvik.se> wrote:
>>>> Hello Hans,
>>>>
>>>> Hans H?bner wrote:
>>>>>>> Peter, as I cannot reproduce the problem myself, can you please post a
>>>>>>> stack backtrace?  Thanks!
>>>> The variable HUNCHENTOOT:*ACCEPTOR* is unbound.
>>>> BREAK was entered because of *BREAK-ON-SIGNALS* (now rebound to NIL).
>>>>   [Condition of type SIMPLE-CONDITION]
>>>>
>>>> Restarts:
>>>>  0: [CONTINUE] Return from BREAK.
>>>>  1: [REASSIGN] Return from BREAK and assign a new value to
>>>> *BREAK-ON-SIGNALS*.
>>>>  2: [TERMINATE-THREAD] Terminate this thread (#<THREAD "Hunchentoot
>>>> listener (*:8000)" RUNNING {C42AAE9}>)
>>>>
>>>> Backtrace:
>>>>  0: (BREAK "~A~%BREAK was entered because of *BREAK-ON-SIGNALS* ~\n
>>>>                (now rebound to NIL)." #<UNBOUND-VARIABLE *ACCEPTOR*
>>>> {AD37FC1}>)
>>>>  1: (SIGNAL #<UNBOUND-VARIABLE *ACCEPTOR* {AD37FC1}>)[:EXTERNAL]
>>>>  2: (ERROR UNBOUND-VARIABLE)[:EXTERNAL]
>>>>  3: (SB-KERNEL::UNBOUND-SYMBOL-ERROR-HANDLER #<unavailable argument>
>>>> #.(SB-SYS:INT-SAP #XB5DFFEF0) #<SB-ALIEN-INTERNALS:ALIEN-VALUE :SAP
>>>> #XB5DFFBDC :TYPE (* (STRUCT SB-VM::OS-CONTEXT-T-STRUCT))> (14))
>>>>  4: (SB-KERNEL::UNBOUND-SYMBOL-ERROR-HANDLER #<unavailable argument>
>>>> #.(SB-SYS:INT-SAP #XB5DFFEF0) #<SB-ALIEN-INTERNALS:ALIEN-VALUE :SAP
>>>> #XB5DFFBDC :TYPE (* (STRUCT SB-VM::OS-CONTEXT-T-STRUCT))> (14))[:EX..
>>>>  5: (SB-KERNEL:INTERNAL-ERROR #.(SB-SYS:INT-SAP #XB5DFFBDC)
>>>> #<unavailable argument>)
>>>>  6: ("foreign function: #x806480C")
>>>>  7: ("foreign function: #x8052BCC")
>>>>  8: ("foreign function: #x8056BD3")
>>>>  9: (HUNCHENTOOT:LOG-MESSAGE :ERROR "Error while creating worker thread
>>>> for new incoming connection: ~A")[:EXTERNAL]
>>>>  10: ((SB-PCL::FAST-METHOD HUNCHENTOOT:HANDLE-INCOMING-CONNECTION
>>>> (HUNCHENTOOT:ONE-THREAD-PER-CONNECTION-TASKMASTER T)) ..)
>>>>  11: ((SB-PCL::FAST-METHOD HUNCHENTOOT:ACCEPT-CONNECTIONS
>>>> (HUNCHENTOOT:ACCEPTOR)) #<unavailable argument> #<unavailable argument>
>>>> #<HUNCHENTOOT:ACCEPTOR (host *, port 8000)>)
>>>>  12: ((FLET SB-THREAD::WITH-MUTEX-THUNK))
>>>>  13: ((FLET #:WITHOUT-INTERRUPTS-BODY-[CALL-WITH-MUTEX]477))
>>>>  14: (SB-THREAD::CALL-WITH-MUTEX ..)
>>>>  15: ((LAMBDA ()))
>>>>  16: ("foreign function: #x806480C")
>>>>  17: ("foreign function: #x8052C21")
>>>>  18: ("foreign function: #x805BD9D")
>>>>  19: ("foreign function: #xB7FB84C0")
>>>>
>>>> I found that not attempting to log a message solved this remaining problem.
>>>>
>>>> Thank you very much for your help!
>>>>
>>>> /Peter
>>>>
>>>>>>> 2009/7/6 Peter Stiernstr?m <peter.stiernstrom at blixtvik.se>:
>>>>>>> Hans,
>>>>>>>
>>>>>>> I should have realised I was editing the lispworks implementation myself
>>>>>>> had I only had a cup of coffee this morning :-P
>>>>>>>
>>>>>>> Now when I tried your patch out I still get hangups but this is another
>>>>>>> kind of hangup:
>>>>>>>
>>>>>>> debugger invoked on a UNBOUND-VARIABLE in thread #<THREAD "Hunchentoot
>>>>>>> listener (*:8000)" RUNNING {AD467D1}>:
>>>>>>>  The variable HUNCHENTOOT:*ACCEPTOR* is unbound.
>>>>>>>
>>>>>>> I am trying this out with the hunchentoot default page by the way.
>>>>>>>
>>>>>>> /Peter
>>>>>>>
>>>>>>> Hans H?bner wrote:
>>>>>>>>>> Peter,
>>>>>>>>>>
>>>>>>>>>> sorry, I am not able to reproduce the problem myself, so I made the
>>>>>>>>>> patch blindly and made a mistake, working on the Lispworks code rather
>>>>>>>>>> than the portable code that affects you.  Please look at the first
>>>>>>>>>> hunk of this diff:
>>>>>>>>>>
>>>>>>>>>> http://bknr.net/trac/changeset/4430?format=diff&new=4430
>>>>>>>>>>
>>>>>>>>>> and let me know if that does it for you.
>>>>>>>>>>
>>>>>>>>>> Sorry,
>>>>>>>>>> Hans
>>>>>>>>>>
>>>>>>>>>> On Mon, Jul 6, 2009 at 11:09, Peter
>>>>>>>>>> Stiernstr?m<peter.stiernstrom at blixtvik.se> wrote:
>>>>>>>>>> Hi Hans,
>>>>>>>>>>
>>>>>>>>>> Hans H?bner wrote:
>>>>>>>>>>>>> Hi Peter,
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2009/7/6 Peter Stiernstr?m <peter.stiernstrom at blixtvik.se>
>>>>>>>>>>>>>> I had a quick peek at client-as-string and it does indeed not handle the
>>>>>>>>>>>>>> sb-bsd-sockets:not-connected-error and if I put a handler-case around
>>>>>>>>>>>>>> body of client-as-string returning nil when the exception appears I can
>>>>>>>>>>>>>> not reproduce my problem anymore.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This wouldn't provide a portable solution though :-P
>>>>>>>>>>>>> This really is a bug that requires fixing in usocket.  There are
>>>>>>>>>>>>> multiple issues:
>>>>>>>>>>>>>
>>>>>>>>>>>>> - As shown in the backtrace, the problem is that the getpeername()
>>>>>>>>>>>>> call fails for a socket that is not connected anymore.  SBCL does the
>>>>>>>>>>>>> right thing by signalling a condition.  Other implementations (I
>>>>>>>>>>>>> checked CCL) seem to behave differently, i.e. return NIL in such a
>>>>>>>>>>>>> case.
>>>>>>>>>>>>>
>>>>>>>>>>>>> - Usocket does not unify the behavior, so the implementation specific
>>>>>>>>>>>>> condition percolates to the caller, Hunchentoot in this case.
>>>>>>>>>>>>>
>>>>>>>>>>>>> - Hunchentoot is not prepared to handle conditions when creating a new
>>>>>>>>>>>>> worker thread.  The call to CLIENT-AS-STRING is made when creating the
>>>>>>>>>>>>> name for the handler process of a new incoming connection, and that is
>>>>>>>>>>>>> done in the context of the server thread.  Therefore, the signalled
>>>>>>>>>>>>> condition will stop the acceptor process.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I spent some thoughts on how a "portable solution" would look like,
>>>>>>>>>>>>> but given that the Lisp implementations vary greatly in behavior,
>>>>>>>>>>>>> fixing usocket would be a pretty large task that I don't have the time
>>>>>>>>>>>>> to do right now.  Thus, I would propose this patch:
>>>>>>>>>>>>>
>>>>>>>>>>>>> http://bknr.net/trac/changeset/4428?format=diff&new=4428
>>>>>>>>>>>>>
>>>>>>>>>>>>> It handles all conditions that are signaled during worker process
>>>>>>>>>>>>> creation, under the theory that we want to prevent the acceptor
>>>>>>>>>>>>> process from crashing under all circumstances.  This is not a clean
>>>>>>>>>>>>> solution in that it may paper over bugs, but given the limited number
>>>>>>>>>>>>> of function invocations that are surrounded by a HANDLER-CASE, I'd say
>>>>>>>>>>>>> that this is a proper intermediate fix.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Please give it a try and let me know if it solves the problem for you.
>>>>>>>>>> I tried your suggested patch but I can't seem to be able to get it to
>>>>>>>>>> catch the exception for me. Were you able to duplicate the error
>>>>>>>>>> yourself to verify that the suggested patch does indeed work? Since I am
>>>>>>>>>> using the 1.0.0 hunchentoot release I couldn't just apply your patch but
>>>>>>>>>> added the handler-case by hand and thus ended up with this in
>>>>>>>>>> taskmaster.lisp:
>>>>>>>>>>
>>>>>>>>>> (defmethod handle-incoming-connection ((taskmaster
>>>>>>>>>> one-thread-per-connection-taskmaster) handle)
>>>>>>>>>>  (incf *worker-counter*)
>>>>>>>>>>  ;; check if we need to perform a global GC
>>>>>>>>>>  (when (and *cleanup-interval*
>>>>>>>>>>             (zerop (mod *worker-counter* *cleanup-interval*)))
>>>>>>>>>>    (when *cleanup-function*
>>>>>>>>>>      (funcall *cleanup-function*)))
>>>>>>>>>>  (handler-case
>>>>>>>>>>      (mp:process-run-function (format nil "Hunchentoot worker \(client:
>>>>>>>>>> ~{~A:~A~})"
>>>>>>>>>>                                       (multiple-value-list
>>>>>>>>>>                                        (get-peer-address-and-port handle)))
>>>>>>>>>>                               nil #'process-connection
>>>>>>>>>>                               (taskmaster-acceptor taskmaster) handle)
>>>>>>>>>>    (error (cond)
>>>>>>>>>>      (log-message *lisp-errors-log-level*
>>>>>>>>>>                   "Error while creating worker thread for new incoming
>>>>>>>>>> connection: ~A" cond))))
>>>>>>>>>>
>>>>>>>>>> /Peter
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>> -Hans
>>>>>>>>>>>>>
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> tbnl-devel site list
>>>>>>>>>>>>> tbnl-devel at common-lisp.net
>>>>>>>>>>>>> http://common-lisp.net/mailman/listinfo/tbnl-devel
>>>>>>> _______________________________________________
>>>>>>> tbnl-devel site list
>>>>>>> tbnl-devel at common-lisp.net
>>>>>>> http://common-lisp.net/mailman/listinfo/tbnl-devel
>>>>>>>>>> _______________________________________________
>>>>>>>>>> tbnl-devel site list
>>>>>>>>>> tbnl-devel at common-lisp.net
>>>>>>>>>> http://common-lisp.net/mailman/listinfo/tbnl-devel
>>>> _______________________________________________
>>>> tbnl-devel site list
>>>> tbnl-devel at common-lisp.net
>>>> http://common-lisp.net/mailman/listinfo/tbnl-devel
>>>>>>> _______________________________________________
>>>>>>> tbnl-devel site list
>>>>>>> tbnl-devel at common-lisp.net
>>>>>>> http://common-lisp.net/mailman/listinfo/tbnl-devel
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>>>> _______________________________________________
>>>> tbnl-devel site list
>>>> tbnl-devel at common-lisp.net
>>>> http://common-lisp.net/mailman/listinfo/tbnl-devel
>>
_______________________________________________
tbnl-devel site list
tbnl-devel at common-lisp.net
http://common-lisp.net/mailman/listinfo/tbnl-devel
>>

> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel

- --
Med v?nlig h?lsning,

Peter Stiernstr?m
0708-810932
Blixtvik AB
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkpR65AACgkQ0brSZD05ZzCQdQCfSv8XnGDeNuMNHYM2UQ8eNGlJ
JMwAoNkaCdJBcpQeA/KTgXvNzRCUvVnx
=MHB+
-----END PGP SIGNATURE-----



From hans.huebner at gmail.com  Mon Jul  6 12:18:10 2009
From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Mon, 6 Jul 2009 14:18:10 +0200
Subject: [hunchentoot-devel] Hunchentoot effective DOS-attack
In-Reply-To: <4A51EB90.20701@blixtvik.se>
References: <4A4DE786.90702@blixtvik.se> <4A51BF44.8080209@blixtvik.se> 
	<fd2982320907060215t542cd599m3f3207e99e520d8a@mail.gmail.com> 
	<4A51D75F.5090303@blixtvik.se>
	<fd2982320907060356ib6cb484ie4da6a686f18cb7d@mail.gmail.com> 
	<4A51DE47.2040301@blixtvik.se>
	<fd2982320907060422t588362cbsa09039a6afd62b8@mail.gmail.com> 
	<4A51E5D2.5050207@blixtvik.se>
	<fd2982320907060459i228af305xc1526bdd3e89c874@mail.gmail.com> 
	<4A51EB90.20701@blixtvik.se>
Message-ID: <fd2982320907060518o4e2ae73s640f3998c0ad3725@mail.gmail.com>

On Mon, Jul 6, 2009 at 14:18, Peter
Stiernstr?m<peter.stiernstrom at blixtvik.se> wrote:
> That seems to fix the last issue I had! Thanks a lot for your time Hans.

Glad to see this to be fixed.

> Should one raise this issue to the attention of the usocket developers
> though?

Can't hurt to send a bug report.

Have a nice day,
Hans



From patrick.may at mac.com  Tue Jul  7 00:24:21 2009
From: patrick.may at mac.com (Patrick May)
Date: Mon, 06 Jul 2009 20:24:21 -0400
Subject: [hunchentoot-devel] ETag, Cache-Control, and/or Expires headers
Message-ID: <93AFC0AD-5345-4ED9-92BF-B895E8DB32FE@mac.com>

	I need to prevent an intermediate cache from caching a static audio  
file I'm providing via register-static-file.  What's the easiest way  
to set these for every reply (changing it dynamically, in the case of  
ETag)?

Thanks,

Patrick




From patrick.may at mac.com  Tue Jul  7 00:43:17 2009
From: patrick.may at mac.com (Patrick May)
Date: Mon, 06 Jul 2009 20:43:17 -0400
Subject: [hunchentoot-devel] ETag, Cache-Control, and/or Expires headers
In-Reply-To: <93AFC0AD-5345-4ED9-92BF-B895E8DB32FE@mac.com>
References: <93AFC0AD-5345-4ED9-92BF-B895E8DB32FE@mac.com>
Message-ID: <BAA9DCAC-1BCF-433F-8C5F-062F5FBA8DA9@mac.com>

	Sorry.  I mean create-static-file-dispatcher-and-handler, not  
register-static-file.

Thanks,

Patrick

On 6 Jul 2009, at 20:24, Patrick May wrote:

> 	I need to prevent an intermediate cache from caching a static audio
> file I'm providing via register-static-file.  What's the easiest way
> to set these for every reply (changing it dynamically, in the case of
> ETag)?
>
> Thanks,
>
> Patrick
>
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel




From patrick.may at mac.com  Tue Jul  7 01:19:20 2009
From: patrick.may at mac.com (Patrick May)
Date: Mon, 06 Jul 2009 21:19:20 -0400
Subject: [hunchentoot-devel] ETag, Cache-Control, and/or Expires headers
In-Reply-To: <BAA9DCAC-1BCF-433F-8C5F-062F5FBA8DA9@mac.com>
References: <93AFC0AD-5345-4ED9-92BF-B895E8DB32FE@mac.com>
	<BAA9DCAC-1BCF-433F-8C5F-062F5FBA8DA9@mac.com>
Message-ID: <DDA1C3ED-5A1A-4F1A-AB4F-504A4042C233@mac.com>

	Since I have the list all to myself tonight, here's the answer I came  
up with:

(defun register-uncached-static-file (name &optional (path *web-path*)
                                                      content-type)
   "Register a static file with Hunchentoot, setting the headers to
   prevent caching.  Dispatcher and handler code lifted from
   hunchentoot:create-static-file-dispatcher-and-handler."
   (push (lambda (request)  ; the dispatcher
           (when (equal (hunchentoot:script-name request)
                        (concatenate 'string "/" name))
             (lambda ()  ; the handler
               (hunchentoot:no-cache)
               (hunchentoot:handle-static-file
                (concatenate 'string path "/" name)
                content-type))))
         hunchentoot:*dispatch-table*))

Comments solicited and appreciated.

Regards,

Patrick

On 6 Jul 2009, at 20:43, Patrick May wrote:

> 	Sorry.  I mean create-static-file-dispatcher-and-handler, not
> register-static-file.
>
> Thanks,
>
> Patrick
>
> On 6 Jul 2009, at 20:24, Patrick May wrote:
>
>> 	I need to prevent an intermediate cache from caching a static audio
>> file I'm providing via register-static-file.  What's the easiest way
>> to set these for every reply (changing it dynamically, in the case of
>> ETag)?
>>
>> Thanks,
>>
>> Patrick
>>
>>
>> _______________________________________________
>> tbnl-devel site list
>> tbnl-devel at common-lisp.net
>> http://common-lisp.net/mailman/listinfo/tbnl-devel
>
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel




From patrick.may at mac.com  Tue Jul  7 18:32:05 2009
From: patrick.may at mac.com (Patrick May)
Date: Tue, 07 Jul 2009 14:32:05 -0400
Subject: [hunchentoot-devel] HTTP 304 behavior (was Re: ETag, Cache-Control,
	and/or Expires headers)
In-Reply-To: <93AFC0AD-5345-4ED9-92BF-B895E8DB32FE@mac.com>
References: <93AFC0AD-5345-4ED9-92BF-B895E8DB32FE@mac.com>
Message-ID: <E48E42D0-103B-493A-8518-4E09C1CB188F@mac.com>

On 6 Jul 2009, at 20:24, Patrick May wrote:
> 	I need to prevent an intermediate cache from caching a static audio
> file I'm providing via register-static-file.  What's the easiest way
> to set these for every reply (changing it dynamically, in the case of
> ETag)?

	I got some feedback from the maintainer of the intermediate cache  
that might be of interest.  The problem I was seeing was that the  
intermediate cache wasn't understanding the type of the audio file I  
was serving.  Both wav and mp3 formats were affected.  It turns out  
that Hunchentoot sends a Content-Type header with a 304 (not modified)  
response.  Apache and other common servers don't.

	RFC2616 section 10.3.5 says:

"If the conditional GET used a strong cache validator (see section  
13.3.3), the response SHOULD NOT include other entity-headers.  
Otherwise (i.e., the conditional GET used a weak validator), the  
response MUST NOT include other entity-headers; this prevents  
inconsistencies between cached entity-bodies and updated headers."

Does this mean Hunchentoot is non-compliant?

Regards,

Patrick




From edi at agharta.de  Tue Jul  7 19:47:02 2009
From: edi at agharta.de (Edi Weitz)
Date: Tue, 7 Jul 2009 21:47:02 +0200
Subject: [hunchentoot-devel] HTTP 304 behavior (was Re: ETag,
	Cache-Control, and/or Expires headers)
In-Reply-To: <E48E42D0-103B-493A-8518-4E09C1CB188F@mac.com>
References: <93AFC0AD-5345-4ED9-92BF-B895E8DB32FE@mac.com>
	<E48E42D0-103B-493A-8518-4E09C1CB188F@mac.com>
Message-ID: <b56421a00907071247r4190df55i614fec7d3da66a1a@mail.gmail.com>

On Tue, Jul 7, 2009 at 8:32 PM, Patrick May<patrick.may at mac.com> wrote:

> Does this mean Hunchentoot is non-compliant?

I haven't looked at this in detail, but from what you quoted it seems
like the function HANDLE-STATIC-FILE (or rather
HANDLE-IF-MODIFIED-SINCE) which a TBNL user provided in 2004 and which
has since essentially been unchanged is indeed non-compliant or rather
too simple-minded.

I don't have the time to fix this right now, but as usual, patches
against the dev version at bknr.net are welcome.

  http://weitz.de/patches.html

Thanks for the report,
Edi.



From alex.paes at streetdogstudio.com  Fri Jul 10 08:47:41 2009
From: alex.paes at streetdogstudio.com (Alexandre Paes)
Date: Fri, 10 Jul 2009 10:47:41 +0200
Subject: [hunchentoot-devel] REF: Re: Hunchentoot 1.0.0 on Lispworks
	Profes sional for windows
In-Reply-To: <fd2982320907031610t33119f7bxd0cae547c6d01255@mail.gmail.com>
References: <wRmSP20ckHmz.kQ4VR3xk@mail.streetdogstudio.com>
	<fd2982320907031610t33119f7bxd0cae547c6d01255@mail.gmail.com>
Message-ID: <20090710104741.bgrhseqlw8ocg4ok@streetdogstudio.com>

Quoting Hans H?bner <hans.huebner at gmail.com>:

> Alexandre,
>
> let's see, here is what I did:
>
> - Get Lispworks 5.1 for Windows from lispworks.com, install on my   
> Vista laptop
> - svn co http://bknr.net/svn/ediware
> - set up asdf:*central-registry*
> - (asdf:oos 'asdf:load-op :hunchentoot-test)
> - load http://localhost:9000/hunchentoot/test in browser
>
> Everything worked as expected.  The svn version of Hunchentoot and its
> dependencies are sufficiently close to the released versions to make
> me believe that you're still using an old version of one of the
> dependencies.
>
> I'm sorry to hear that you're having a hard time getting Hunchentoot
> to run, but I think you can rest assured that this is not because it
> does not work.  It is more likely that you need to acquire some more
> experience with your Lisp environment.  Please don't give up!
>
> -Hans
>

Hi Hans,

I have been on vacations so i have only tested this approach today,  
but i can confirm that this does indeed work. Thank you for your help  
solving this issue.


Cheers,

Alexandre Paes





From peter at gigamonkeys.com  Tue Jul 21 23:09:30 2009
From: peter at gigamonkeys.com (Peter Seibel)
Date: Tue, 21 Jul 2009 16:09:30 -0700
Subject: [hunchentoot-devel] Fwd: Problem with late calls to POST-PARAMETERS
In-Reply-To: <40e4e7e50906011421s48444931g20c3e17a5b819647@mail.gmail.com>
References: <40e4e7e50906011421s48444931g20c3e17a5b819647@mail.gmail.com>
Message-ID: <40e4e7e50907211609m5ef068acye7a0fed0346acaff@mail.gmail.com>

I sent this almost two months ago when Edi was very busy. I'm hoping
someone can tell me if this is a righteous patch.

-Peter


---------- Forwarded message ----------
From: Peter Seibel <peter at gigamonkeys.com>
Date: Mon, Jun 1, 2009 at 2:21 PM
Subject: Problem with late calls to POST-PARAMETERS
To: tbnl-devel at common-lisp.net


I ran into a problem converting some of my code to run with
Hunchentoot 1.0. This patch fixes it and -- as far as I can tell after
a bit of poking around -- is possibly righteous. What do you think?
The basic problem that I ran into is explained in the comment in the
patch.

-Peter

diff -r 635083ac9419 hunchentoot/request.lisp
--- a/hunchentoot/request.lisp ?Sun May 31 11:31:25 2009 -0700
+++ b/hunchentoot/request.lisp ?Mon Jun 01 14:19:19 2009 -0700
@@ -346,7 +346,12 @@
? (get-parameters request))

?(defmethod post-parameters :before ((request request))
- ?(maybe-read-post-parameters :request request))
+ ?;; Force here because if someone calls POST-PARAMETERS they actually
+ ?;; want them, regardless of why the RAW-POST-DATA has been filled
+ ?;; in. (For instance, if SEND-HEADERS has been called, filling in
+ ?;; RAW-POST-DATA, and then subsequent code calls POST-PARAMETERS,
+ ?;; without the :FORCE flag POST-PARAMETERS would return NIL.)
+ ?(maybe-read-post-parameters :request request :force t))

?(defun post-parameters* (&optional (request *request*))
? "Returns an alist of the POST parameters associated with the REQUEST


--
Peter Seibel
http://www.codersatwork.com/
http://www.gigamonkeys.com/blog/



-- 
Peter Seibel
http://www.codersatwork.com/
http://www.gigamonkeys.com/blog/



From sky at viridian-project.de  Wed Jul 22 07:45:12 2009
From: sky at viridian-project.de (Leslie P. Polzer)
Date: Wed, 22 Jul 2009 09:45:12 +0200 (CEST)
Subject: [hunchentoot-devel] Fwd: Problem with late calls to
 POST-PARAMETERS
In-Reply-To: <40e4e7e50907211609m5ef068acye7a0fed0346acaff@mail.gmail.com>
References: <40e4e7e50906011421s48444931g20c3e17a5b819647@mail.gmail.com>
	<40e4e7e50907211609m5ef068acye7a0fed0346acaff@mail.gmail.com>
Message-ID: <67684cbacb09f0720be9b60fd55094ad.squirrel@mail.stardawn.org>


Peter Seibel wrote:
> I sent this almost two months ago when Edi was very busy. I'm hoping
> someone can tell me if this is a righteous patch.

I'll try to make a start:

What's the use case for this? Why set RAW-POST-DATA and then attempt
to read it again using POST-PARAMETERS?

  Leslie

-- 
http://www.linkedin.com/in/polzer




From sky at viridian-project.de  Wed Jul 22 14:33:19 2009
From: sky at viridian-project.de (Leslie P. Polzer)
Date: Wed, 22 Jul 2009 16:33:19 +0200 (CEST)
Subject: [hunchentoot-devel] Fwd: Problem with late calls to
 POST-PARAMETERS
In-Reply-To: <40e4e7e50907220730v1c64a7bcgcdd2d5c4b63fad67@mail.gmail.com>
References: <40e4e7e50906011421s48444931g20c3e17a5b819647@mail.gmail.com>
	<40e4e7e50907211609m5ef068acye7a0fed0346acaff@mail.gmail.com>
	<67684cbacb09f0720be9b60fd55094ad.squirrel@mail.stardawn.org>
	<40e4e7e50907220730v1c64a7bcgcdd2d5c4b63fad67@mail.gmail.com>
Message-ID: <7369446bd8bdebdc46b87803cad1326c.squirrel@mail.stardawn.org>


Peter Seibel wrote:
> Because I didn't call RAW-POST-DATA; it was called by the Hunchentoot
> internals when I called SEND-HEADERS. And after that without my patch
> you can no longer get anything via POST-PARAMETERS. I don't see any
> reason that calling SEND-HEADERS should make it impossible to get at
> POST-PARAMETERS (and pre-1.0 it didn't which is how I ran into this
> problem--my previously working code stopped working when I upgraded to
> 1.0)

I see. So is there a pressing reason to call SEND-HEADERS before
collecting post parameters?

  Leslie

-- 
http://www.linkedin.com/in/polzer




From peter at gigamonkeys.com  Wed Jul 22 14:44:06 2009
From: peter at gigamonkeys.com (Peter Seibel)
Date: Wed, 22 Jul 2009 07:44:06 -0700
Subject: [hunchentoot-devel] Fwd: Problem with late calls to
	POST-PARAMETERS
In-Reply-To: <7369446bd8bdebdc46b87803cad1326c.squirrel@mail.stardawn.org>
References: <40e4e7e50906011421s48444931g20c3e17a5b819647@mail.gmail.com>
	<40e4e7e50907211609m5ef068acye7a0fed0346acaff@mail.gmail.com>
	<67684cbacb09f0720be9b60fd55094ad.squirrel@mail.stardawn.org>
	<40e4e7e50907220730v1c64a7bcgcdd2d5c4b63fad67@mail.gmail.com>
	<7369446bd8bdebdc46b87803cad1326c.squirrel@mail.stardawn.org>
Message-ID: <40e4e7e50907220744o1cb61f2l5cfd355daef886c2@mail.gmail.com>

On Wed, Jul 22, 2009 at 7:33 AM, Leslie P.
Polzer<sky at viridian-project.de> wrote:
>
> Peter Seibel wrote:
>> Because I didn't call RAW-POST-DATA; it was called by the Hunchentoot
>> internals when I called SEND-HEADERS. And after that without my patch
>> you can no longer get anything via POST-PARAMETERS. I don't see any
>> reason that calling SEND-HEADERS should make it impossible to get at
>> POST-PARAMETERS (and pre-1.0 it didn't which is how I ran into this
>> problem--my previously working code stopped working when I upgraded to
>> 1.0)
>
> I see. So is there a pressing reason to call SEND-HEADERS before
> collecting post parameters?

Well, a big pile of previously working code. And if you're not allowed
to call POST-PARAMETERS after SEND-HEADERS then the docs should say
so. So is it easier to patch the code to allow the old (and sometimes
useful behavior) or patch the docs to reflect a somewhat arbitrary
restriction?

-Peter


-- 
Peter Seibel
http://www.codersatwork.com/
http://www.gigamonkeys.com/blog/



From peter at gigamonkeys.com  Wed Jul 22 14:47:09 2009
From: peter at gigamonkeys.com (Peter Seibel)
Date: Wed, 22 Jul 2009 07:47:09 -0700
Subject: [hunchentoot-devel] Fwd: Problem with late calls to
	POST-PARAMETERS
In-Reply-To: <40e4e7e50907220744o1cb61f2l5cfd355daef886c2@mail.gmail.com>
References: <40e4e7e50906011421s48444931g20c3e17a5b819647@mail.gmail.com>
	<40e4e7e50907211609m5ef068acye7a0fed0346acaff@mail.gmail.com>
	<67684cbacb09f0720be9b60fd55094ad.squirrel@mail.stardawn.org>
	<40e4e7e50907220730v1c64a7bcgcdd2d5c4b63fad67@mail.gmail.com>
	<7369446bd8bdebdc46b87803cad1326c.squirrel@mail.stardawn.org>
	<40e4e7e50907220744o1cb61f2l5cfd355daef886c2@mail.gmail.com>
Message-ID: <40e4e7e50907220747pb75d4f1ka9f1c88c2b39aac4@mail.gmail.com>

I think the actual problem I had was some code that did essentially:

  (with-foo-output ((send-headers))
     (expand-template-file))

where expand-template-file calls code that uses post-parameters to get
at, well, post parameters. It's not clear how to easily turn that code
inside out so all the parameters are gathered in advance of calling
send-headers.

-Peter

On Wed, Jul 22, 2009 at 7:44 AM, Peter Seibel<peter at gigamonkeys.com> wrote:
> On Wed, Jul 22, 2009 at 7:33 AM, Leslie P.
> Polzer<sky at viridian-project.de> wrote:
>>
>> Peter Seibel wrote:
>>> Because I didn't call RAW-POST-DATA; it was called by the Hunchentoot
>>> internals when I called SEND-HEADERS. And after that without my patch
>>> you can no longer get anything via POST-PARAMETERS. I don't see any
>>> reason that calling SEND-HEADERS should make it impossible to get at
>>> POST-PARAMETERS (and pre-1.0 it didn't which is how I ran into this
>>> problem--my previously working code stopped working when I upgraded to
>>> 1.0)
>>
>> I see. So is there a pressing reason to call SEND-HEADERS before
>> collecting post parameters?
>
> Well, a big pile of previously working code. And if you're not allowed
> to call POST-PARAMETERS after SEND-HEADERS then the docs should say
> so. So is it easier to patch the code to allow the old (and sometimes
> useful behavior) or patch the docs to reflect a somewhat arbitrary
> restriction?
>
> -Peter
>
>
> --
> Peter Seibel
> http://www.codersatwork.com/
> http://www.gigamonkeys.com/blog/
>



-- 
Peter Seibel
http://www.codersatwork.com/
http://www.gigamonkeys.com/blog/



From peter at gigamonkeys.com  Wed Jul 22 14:30:25 2009
From: peter at gigamonkeys.com (Peter Seibel)
Date: Wed, 22 Jul 2009 07:30:25 -0700
Subject: [hunchentoot-devel] Fwd: Problem with late calls to
	POST-PARAMETERS
In-Reply-To: <67684cbacb09f0720be9b60fd55094ad.squirrel@mail.stardawn.org>
References: <40e4e7e50906011421s48444931g20c3e17a5b819647@mail.gmail.com>
	<40e4e7e50907211609m5ef068acye7a0fed0346acaff@mail.gmail.com>
	<67684cbacb09f0720be9b60fd55094ad.squirrel@mail.stardawn.org>
Message-ID: <40e4e7e50907220730v1c64a7bcgcdd2d5c4b63fad67@mail.gmail.com>

Because I didn't call RAW-POST-DATA; it was called by the Hunchentoot
internals when I called SEND-HEADERS. And after that without my patch
you can no longer get anything via POST-PARAMETERS. I don't see any
reason that calling SEND-HEADERS should make it impossible to get at
POST-PARAMETERS (and pre-1.0 it didn't which is how I ran into this
problem--my previously working code stopped working when I upgraded to
1.0)

-Peter

On Wed, Jul 22, 2009 at 12:45 AM, Leslie P.
Polzer<sky at viridian-project.de> wrote:
>
> Peter Seibel wrote:
>> I sent this almost two months ago when Edi was very busy. I'm hoping
>> someone can tell me if this is a righteous patch.
>
> I'll try to make a start:
>
> What's the use case for this? Why set RAW-POST-DATA and then attempt
> to read it again using POST-PARAMETERS?
>
> ?Leslie
>
> --
> http://www.linkedin.com/in/polzer
>
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>



-- 
Peter Seibel
http://www.codersatwork.com/
http://www.gigamonkeys.com/blog/



From sky at viridian-project.de  Wed Jul 22 15:09:23 2009
From: sky at viridian-project.de (Leslie P. Polzer)
Date: Wed, 22 Jul 2009 17:09:23 +0200 (CEST)
Subject: [hunchentoot-devel] Fwd: Problem with late calls to
 POST-PARAMETERS
In-Reply-To: <40e4e7e50907220744o1cb61f2l5cfd355daef886c2@mail.gmail.com>
References: <40e4e7e50906011421s48444931g20c3e17a5b819647@mail.gmail.com>
	<40e4e7e50907211609m5ef068acye7a0fed0346acaff@mail.gmail.com>
	<67684cbacb09f0720be9b60fd55094ad.squirrel@mail.stardawn.org>
	<40e4e7e50907220730v1c64a7bcgcdd2d5c4b63fad67@mail.gmail.com>
	<7369446bd8bdebdc46b87803cad1326c.squirrel@mail.stardawn.org>
	<40e4e7e50907220744o1cb61f2l5cfd355daef886c2@mail.gmail.com>
Message-ID: <46f6bcfd9617d7d5a61880e8ced87874.squirrel@mail.stardawn.org>


Peter Seibel wrote:

> Well, a big pile of previously working code. And if you're not allowed
> to call POST-PARAMETERS after SEND-HEADERS then the docs should say
> so. So is it easier to patch the code to allow the old (and sometimes
> useful behavior) or patch the docs to reflect a somewhat arbitrary
> restriction?

I'd rather have the former. In fact I'd been in favor of that patch
before, but it seemed necessary in any case to discuss the benefits.

I can't commit your patch but I hope this discussion helps Hans
and Edi to do so.

  Leslie

-- 
http://www.linkedin.com/in/polzer




From edi at agharta.de  Wed Jul 22 16:26:21 2009
From: edi at agharta.de (Edi Weitz)
Date: Wed, 22 Jul 2009 18:26:21 +0200
Subject: [hunchentoot-devel] Fwd: Problem with late calls to
	POST-PARAMETERS
In-Reply-To: <46f6bcfd9617d7d5a61880e8ced87874.squirrel@mail.stardawn.org>
References: <40e4e7e50906011421s48444931g20c3e17a5b819647@mail.gmail.com>
	<40e4e7e50907211609m5ef068acye7a0fed0346acaff@mail.gmail.com>
	<67684cbacb09f0720be9b60fd55094ad.squirrel@mail.stardawn.org>
	<40e4e7e50907220730v1c64a7bcgcdd2d5c4b63fad67@mail.gmail.com>
	<7369446bd8bdebdc46b87803cad1326c.squirrel@mail.stardawn.org>
	<40e4e7e50907220744o1cb61f2l5cfd355daef886c2@mail.gmail.com>
	<46f6bcfd9617d7d5a61880e8ced87874.squirrel@mail.stardawn.org>
Message-ID: <b56421a00907220926j539c428cr2c79767c5a918497@mail.gmail.com>

On Wed, Jul 22, 2009 at 5:09 PM, Leslie P.
Polzer<sky at viridian-project.de> wrote:

> I can't commit your patch but I hope this discussion helps Hans
> and Edi to do so.

It did.  And it reminded us to finally do something... :)

I agree that Peter's patch looks OK and is generally to be preferred
over disallowing to use POST-PARAMETERS after having called
SEND-HEADERS.  However, as a general style rule, I'd recommend to do
as much work as possible /before/ calling SEND-HEADERS (i.e. while
errors can still be handled gracefully).

Patch will be applied to the dev version.

Thanks,
Edi.



From peter at gigamonkeys.com  Wed Jul 22 16:41:47 2009
From: peter at gigamonkeys.com (Peter Seibel)
Date: Wed, 22 Jul 2009 09:41:47 -0700
Subject: [hunchentoot-devel] Fwd: Problem with late calls to
	POST-PARAMETERS
In-Reply-To: <fd2982320907220925y7a6fc8f7q454596ae0964eaf6@mail.gmail.com>
References: <40e4e7e50906011421s48444931g20c3e17a5b819647@mail.gmail.com>
	<40e4e7e50907211609m5ef068acye7a0fed0346acaff@mail.gmail.com>
	<67684cbacb09f0720be9b60fd55094ad.squirrel@mail.stardawn.org>
	<40e4e7e50907220730v1c64a7bcgcdd2d5c4b63fad67@mail.gmail.com>
	<7369446bd8bdebdc46b87803cad1326c.squirrel@mail.stardawn.org>
	<40e4e7e50907220744o1cb61f2l5cfd355daef886c2@mail.gmail.com>
	<46f6bcfd9617d7d5a61880e8ced87874.squirrel@mail.stardawn.org>
	<fd2982320907220925y7a6fc8f7q454596ae0964eaf6@mail.gmail.com>
Message-ID: <40e4e7e50907220941x76cf1fe5pb2606ec0eacbe6a@mail.gmail.com>

Cool, thanks guys.

-Peter

On Wed, Jul 22, 2009 at 9:25 AM, Hans H?bner<hans.huebner at gmail.com> wrote:
> Peter, I have committed your fix to the development version of
> Hunchentoot. ?Leslie, thank you for reviewing it!
>
> Apologies for the long time that this took.
>
> -Hans
>
> On Wed, Jul 22, 2009 at 17:09, Leslie P. Polzer<sky at viridian-project.de> wrote:
>>
>> Peter Seibel wrote:
>>
>>> Well, a big pile of previously working code. And if you're not allowed
>>> to call POST-PARAMETERS after SEND-HEADERS then the docs should say
>>> so. So is it easier to patch the code to allow the old (and sometimes
>>> useful behavior) or patch the docs to reflect a somewhat arbitrary
>>> restriction?
>>
>> I'd rather have the former. In fact I'd been in favor of that patch
>> before, but it seemed necessary in any case to discuss the benefits.
>>
>> I can't commit your patch but I hope this discussion helps Hans
>> and Edi to do so.
>>
>> ?Leslie
>>
>> --
>> http://www.linkedin.com/in/polzer
>>
>>
>> _______________________________________________
>> tbnl-devel site list
>> tbnl-devel at common-lisp.net
>> http://common-lisp.net/mailman/listinfo/tbnl-devel
>>
>



-- 
Peter Seibel
http://www.codersatwork.com/
http://www.gigamonkeys.com/blog/



From hans.huebner at gmail.com  Wed Jul 22 16:25:59 2009
From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Wed, 22 Jul 2009 18:25:59 +0200
Subject: [hunchentoot-devel] Fwd: Problem with late calls to
	POST-PARAMETERS
In-Reply-To: <46f6bcfd9617d7d5a61880e8ced87874.squirrel@mail.stardawn.org>
References: <40e4e7e50906011421s48444931g20c3e17a5b819647@mail.gmail.com> 
	<40e4e7e50907211609m5ef068acye7a0fed0346acaff@mail.gmail.com> 
	<67684cbacb09f0720be9b60fd55094ad.squirrel@mail.stardawn.org> 
	<40e4e7e50907220730v1c64a7bcgcdd2d5c4b63fad67@mail.gmail.com> 
	<7369446bd8bdebdc46b87803cad1326c.squirrel@mail.stardawn.org> 
	<40e4e7e50907220744o1cb61f2l5cfd355daef886c2@mail.gmail.com> 
	<46f6bcfd9617d7d5a61880e8ced87874.squirrel@mail.stardawn.org>
Message-ID: <fd2982320907220925y7a6fc8f7q454596ae0964eaf6@mail.gmail.com>

Peter, I have committed your fix to the development version of
Hunchentoot.  Leslie, thank you for reviewing it!

Apologies for the long time that this took.

-Hans

On Wed, Jul 22, 2009 at 17:09, Leslie P. Polzer<sky at viridian-project.de> wrote:
>
> Peter Seibel wrote:
>
>> Well, a big pile of previously working code. And if you're not allowed
>> to call POST-PARAMETERS after SEND-HEADERS then the docs should say
>> so. So is it easier to patch the code to allow the old (and sometimes
>> useful behavior) or patch the docs to reflect a somewhat arbitrary
>> restriction?
>
> I'd rather have the former. In fact I'd been in favor of that patch
> before, but it seemed necessary in any case to discuss the benefits.
>
> I can't commit your patch but I hope this discussion helps Hans
> and Edi to do so.
>
> ?Leslie
>
> --
> http://www.linkedin.com/in/polzer
>
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>



From sky at viridian-project.de  Wed Jul 29 09:27:06 2009
From: sky at viridian-project.de (Leslie P. Polzer)
Date: Wed, 29 Jul 2009 11:27:06 +0200 (CEST)
Subject: [hunchentoot-devel] Exporting HANDLER-DONE
Message-ID: <13f343c98aa746035147e293e814f823.squirrel@mail.stardawn.org>


This is a useful throw tag that should be part of the public
API. Would anyone object against exporting this in the next
version?

  Leslie

-- 
http://www.linkedin.com/in/polzer




From hans.huebner at gmail.com  Wed Jul 29 09:37:37 2009
From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Wed, 29 Jul 2009 05:37:37 -0400
Subject: [hunchentoot-devel] Exporting HANDLER-DONE
In-Reply-To: <13f343c98aa746035147e293e814f823.squirrel@mail.stardawn.org>
References: <13f343c98aa746035147e293e814f823.squirrel@mail.stardawn.org>
Message-ID: <fd2982320907290237n58656c52rf9019a05b973b66e@mail.gmail.com>

Leslie, can you come up with some proposed documentation for the
HANDLER-DONE tag?  I'm not saying that I'm convinced yet, but maybe a
documentation entry would do.

-Hans

On Wed, Jul 29, 2009 at 05:27, Leslie P. Polzer<sky at viridian-project.de> wrote:
>
> This is a useful throw tag that should be part of the public
> API. Would anyone object against exporting this in the next
> version?
>
> ?Leslie
>
> --
> http://www.linkedin.com/in/polzer
>
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>



From sky at viridian-project.de  Wed Jul 29 09:58:33 2009
From: sky at viridian-project.de (Leslie P. Polzer)
Date: Wed, 29 Jul 2009 11:58:33 +0200 (CEST)
Subject: [hunchentoot-devel] Exporting HANDLER-DONE
In-Reply-To: <b56421a00907290256x132a2769ycb0c06210582aa81@mail.gmail.com>
References: <13f343c98aa746035147e293e814f823.squirrel@mail.stardawn.org>
	<b56421a00907290256x132a2769ycb0c06210582aa81@mail.gmail.com>
Message-ID: <7c244ab960364ef50bf8108a44b92dec.squirrel@mail.stardawn.org>


Edi Weitz wrote:

>   http://weitz.de/hunchentoot/#abort-request-handler

Wow, I totally missed that one. Thanks!

  Leslie

-- 
http://www.linkedin.com/in/polzer




From edi at agharta.de  Wed Jul 29 09:56:44 2009
From: edi at agharta.de (Edi Weitz)
Date: Wed, 29 Jul 2009 11:56:44 +0200
Subject: [hunchentoot-devel] Exporting HANDLER-DONE
In-Reply-To: <13f343c98aa746035147e293e814f823.squirrel@mail.stardawn.org>
References: <13f343c98aa746035147e293e814f823.squirrel@mail.stardawn.org>
Message-ID: <b56421a00907290256x132a2769ycb0c06210582aa81@mail.gmail.com>

On Wed, Jul 29, 2009 at 11:27 AM, Leslie P. Polzer
<sky at viridian-project.de> wrote:

> This is a useful throw tag that should be part of the public
> API. Would anyone object against exporting this in the next
> version?

  http://weitz.de/hunchentoot/#abort-request-handler

Edi.