From edi at agharta.de  Thu Oct  1 07:32:57 2009
From: edi at agharta.de (Edi Weitz)
Date: Thu, 1 Oct 2009 09:32:57 +0200
Subject: [hunchentoot-devel] Small patch for LispWorks 6 beta
In-Reply-To: <fd2982320909301604p1a2a8387ke8dd5839202bc2a4@mail.gmail.com>
References: <873a64ny5s.fsf@galileo.bitart.cc>
	<fd2982320909301604p1a2a8387ke8dd5839202bc2a4@mail.gmail.com>
Message-ID: <b56421a00910010032j4edc7e8au4e16a4b9d294c335@mail.gmail.com>

On Thu, Oct 1, 2009 at 1:04 AM, Hans H?bner <hans.huebner at gmail.com> wrote:
> The patch does not look as if it worked for the Lispworks 4 case.

LW4 didn't have write timeouts (and, yes, I think some people still use it).

I guess Nico wanted to have #- instead of #+ in there, but I think
it's safer, although a bit more clumsy, to specifically mention LW5
and LW6 (which, as we know from the ECLM, will be released soon).

Thanks,
Edi.



From ndj at bitart.cc  Thu Oct  1 18:49:29 2009
From: ndj at bitart.cc (Nico de Jager)
Date: Thu, 01 Oct 2009 20:49:29 +0200
Subject: [hunchentoot-devel] Small patch for LispWorks 6 beta
In-Reply-To: <fd2982320909301604p1a2a8387ke8dd5839202bc2a4@mail.gmail.com>
	("Hans =?utf-8?Q?H=C3=BCbner=22's?= message of "Wed,
	30 Sep 2009 16:04:54 -0700")
References: <873a64ny5s.fsf@galileo.bitart.cc>
	<fd2982320909301604p1a2a8387ke8dd5839202bc2a4@mail.gmail.com>
Message-ID: <87ws3fhruu.fsf@galileo.bitart.cc>

Hi Edi & Hans!

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

> The patch does not look as if it worked for the Lispworks 4 case.

No, it is meant to work for LispWorks 4.x as well, see below.


> Is LW 4 still in use?  It might be sensible to remove support for it
> instead, but that'd be basically Edi's call.
>
> -Hans
>
> On Wed, Sep 30, 2009 at 10:24, Nico de Jager <ndj at bitart.cc> wrote:
>> $ diff -u lispworks.lisp_orig lispworks.lisp_patched
>> --- lispworks.lisp_orig 2009-09-30 11:42:22.000000000 +0200
>> +++ lispworks.lisp_patched ? ? ?2009-09-30 19:06:22.118317238 +0200
>> @@ -90,14 +90,14 @@
>> ?(defun make-socket-stream (socket acceptor)
>> ? "Returns a stream for the socket SOCKET. ?The ACCEPTOR argument is
>> ?used to set the timeouts."
>> - ?#-:lispworks5
>> + ?#+:lispworks4
>> ? (when (acceptor-write-timeout acceptor)
>> ? ? (parameter-error "You need LispWorks 5 or higher for write timeouts."))
>> ? (make-instance 'comm:socket-stream
>> ? ? ? ? ? ? ? ? ?:socket socket
>> ? ? ? ? ? ? ? ? ?:direction :io
>> ? ? ? ? ? ? ? ? ?:read-timeout (acceptor-read-timeout acceptor)
>> - ? ? ? ? ? ? ? ? #+:lispworks5 #+:lispworks5
>> + ? ? ? ? ? ? ? ? #-:lispworks4
>> ? ? ? ? ? ? ? ? ?:write-timeout (acceptor-write-timeout acceptor)
>> ? ? ? ? ? ? ? ? ?:element-type 'octet))

Edi Weitz <edi at agharta.de> writes:

> On Thu, Oct 1, 2009 at 1:04 AM, Hans H?bner <hans.huebner at gmail.com> wrote:
>> The patch does not look as if it worked for the Lispworks 4 case.
>
> LW4 didn't have write timeouts (and, yes, I think some people still
> use it).

Yes.


> I guess Nico wanted to have #- instead of #+ in there,

No, it is as intended. Please correct me if I am having a brain fart.


> but I think it's safer, although a bit more clumsy, to specifically
> mention LW5 and LW6 (which, as we know from the ECLM, will be released
> soon).

The first patch I sent to Edi privately, was as the one at the
bottom. But isn't 

#+:lispworks4  ==  #-(or :lispworks5 :lispworks6)
and
#-:lispworks4  ==  #+(or :lispworks5 :lispworks6)

when we are only considering version 4, 5 and 6? In fact, the patch at
the top is better, since when LispWorks 7.x comes out the patch above
will already work as it covers versions 4 and higher, but the patch
below will have to be amended, since it only covers version 4, 5 and
6. Which one is clearer, is subjective - I like the one at the top
because the exceptions is specifically for LispWorks4 and for the reason
described in the previous sentence.

B.t.w. the double #+:lispworks5 #+:lispworks5 in the original code is a
(harmless) mistake, correct?

Regards.
Nico

$ diff -u lispworks.lisp_orig lispworks.lisp_patched2
--- lispworks.lisp_orig 2009-09-30 11:42:22.000000000 +0200
+++ lispworks.lisp_patched2     2009-10-01 18:58:19.102193637 +0200
@@ -90,14 +90,14 @@
 (defun make-socket-stream (socket acceptor)
   "Returns a stream for the socket SOCKET.  The ACCEPTOR argument is
 used to set the timeouts."
-  #-:lispworks5
+  #-(or :lispworks5 :lispworks6)
   (when (acceptor-write-timeout acceptor)
     (parameter-error "You need LispWorks 5 or higher for write timeouts."))
   (make-instance 'comm:socket-stream
                  :socket socket
                  :direction :io
                  :read-timeout (acceptor-read-timeout acceptor)
-                 #+:lispworks5 #+:lispworks5
+                 #+(or :lispworks5 :lispworks6)
                  :write-timeout (acceptor-write-timeout acceptor)
                  :element-type 'octet))




From edi at agharta.de  Thu Oct  1 21:08:49 2009
From: edi at agharta.de (Edi Weitz)
Date: Thu, 1 Oct 2009 23:08:49 +0200
Subject: [hunchentoot-devel] Small patch for LispWorks 6 beta
In-Reply-To: <87ws3fhruu.fsf@galileo.bitart.cc>
References: <873a64ny5s.fsf@galileo.bitart.cc>
	<fd2982320909301604p1a2a8387ke8dd5839202bc2a4@mail.gmail.com>
	<87ws3fhruu.fsf@galileo.bitart.cc>
Message-ID: <b56421a00910011408s606f05d4s909469b6357f1635@mail.gmail.com>

On Thu, Oct 1, 2009 at 8:49 PM, Nico de Jager <ndj at bitart.cc> wrote:

> No, it is as intended. Please correct me if I am having a brain fart.

My bad.  I didn't look closely enough.

> The first patch I sent to Edi privately, was as the one at the
> bottom. But isn't
>
> #+:lispworks4 ?== ?#-(or :lispworks5 :lispworks6)
> and
> #-:lispworks4 ?== ?#+(or :lispworks5 :lispworks6)
>
> when we are only considering version 4, 5 and 6? In fact, the patch at
> the top is better, since when LispWorks 7.x comes out the patch above
> will already work as it covers versions 4 and higher, but the patch
> below will have to be amended, since it only covers version 4, 5 and
> 6. Which one is clearer, is subjective - I like the one at the top
> because the exceptions is specifically for LispWorks4 and for the reason
> described in the previous sentence.

What I don't like about this is that it doesn't take LW3 into account... :)

Only half joking, really.  Starting with LW4 seems a rather arbitrary
assumption to me although the code very likely won't work with LW3
anyway, but the code isn't self-documenting anymore.  #-:lispworks4
says "for all except LW4" while you actually wanted to say "for LW5
and LW6 and maybe LW7 as well".

> B.t.w. the double #+:lispworks5 #+:lispworks5 in the original code is a
> (harmless) mistake, correct?

No, it's on purpose.  It affects the /two/ forms following it and your
patch must also take care of two forms.

Thanks,
Edi.



From ndj at bitart.cc  Fri Oct  2 18:05:44 2009
From: ndj at bitart.cc (Nico de Jager)
Date: Fri, 02 Oct 2009 20:05:44 +0200
Subject: [hunchentoot-devel] Small patch for LispWorks 6 beta
In-Reply-To: <b56421a00910011408s606f05d4s909469b6357f1635@mail.gmail.com>
	(Edi Weitz's message of "Thu, 1 Oct 2009 23:08:49 +0200")
References: <873a64ny5s.fsf@galileo.bitart.cc>
	<fd2982320909301604p1a2a8387ke8dd5839202bc2a4@mail.gmail.com>
	<87ws3fhruu.fsf@galileo.bitart.cc>
	<b56421a00910011408s606f05d4s909469b6357f1635@mail.gmail.com>
Message-ID: <87tyyhbrif.fsf@galileo.bitart.cc>

Edi Weitz <edi at agharta.de> writes:

> On Thu, Oct 1, 2009 at 8:49 PM, Nico de Jager <ndj at bitart.cc> wrote:
>
>> No, it is as intended. Please correct me if I am having a brain fart.
>
> My bad.  I didn't look closely enough.
>
>> The first patch I sent to Edi privately, was as the one at the
>> bottom. But isn't
>>
>> #+:lispworks4 ?== ?#-(or :lispworks5 :lispworks6)
>> and
>> #-:lispworks4 ?== ?#+(or :lispworks5 :lispworks6)
>>
>> when we are only considering version 4, 5 and 6? In fact, the patch at
>> the top is better, since when LispWorks 7.x comes out the patch above
>> will already work as it covers versions 4 and higher, but the patch
>> below will have to be amended, since it only covers version 4, 5 and
>> 6. Which one is clearer, is subjective - I like the one at the top
>> because the exceptions is specifically for LispWorks4 and for the reason
>> described in the previous sentence.
>
> What I don't like about this is that it doesn't take LW3 into account... :)
>
> Only half joking, really.  Starting with LW4 seems a rather arbitrary
> assumption to me although the code very likely won't work with LW3
> anyway, but the code isn't self-documenting anymore.  #-:lispworks4
> says "for all except LW4" while you actually wanted to say "for LW5
> and LW6 and maybe LW7 as well".

But..., hmm..., ok. :-)


>> B.t.w. the double #+:lispworks5 #+:lispworks5 in the original code is a
>> (harmless) mistake, correct?
>
> No, it's on purpose.  It affects the /two/ forms following it and your
> patch must also take care of two forms.

I see - thanks Edi. Back to the CLHS then...

Below, is another attempt.

Regards.
Nico


$ diff -u lispworks.lisp lispworks.lisp_patched3
--- lispworks.lisp      2009-02-17 00:14:24.000000000 +0200
+++ lispworks.lisp_patched3     2009-10-02 20:03:58.986727798 +0200
@@ -90,14 +90,14 @@
 (defun make-socket-stream (socket acceptor)
   "Returns a stream for the socket SOCKET.  The ACCEPTOR argument is
 used to set the timeouts."
-  #-:lispworks5
+  #-(or :lispworks5 :lispworks6)
   (when (acceptor-write-timeout acceptor)
     (parameter-error "You need LispWorks 5 or higher for write timeouts."))
   (make-instance 'comm:socket-stream
                  :socket socket
                  :direction :io
                  :read-timeout (acceptor-read-timeout acceptor)
-                 #+:lispworks5 #+:lispworks5
+                 #+(or :lispworks5 :lispworks6) #+(or :lispworks5 :lispworks6)
                  :write-timeout (acceptor-write-timeout acceptor)
                  :element-type 'octet))




From sebyte at smolny.plus.com  Thu Oct  8 19:27:03 2009
From: sebyte at smolny.plus.com (Sebastian Tennant)
Date: Thu, 08 Oct 2009 19:27:03 +0000
Subject: [hunchentoot-devel] Default external format
Message-ID: <pr8xu1o8.fsf@vps203.linuxvps.org>

Hi list,

I don't often see messages of thanks on open source software mailing lists, so,
without wishing to sound obsequious, let me buck the trend by thanking Edi, and
everone else, before and since, for their work on hunchentoot.

I've found that setting this at the top level of cl-user:

 (setf tbnl:*hunchentoot-default-external-format* tbnl::+utf-8+)

has no effect, other than preventing an error when a handler produces non-ascii
text, i.e., the non-ascii text is garbled when displayed in the browser,
despite including the line:

 (setf (tbnl:content-type*) "text/html; charset=utf-8")

in the handler.

The problem is solved by also including the line:

 (setf (tbnl:reply-external-format tbnl:*REPLY*) tbnl::+utf-8+)

in the handler, so what then is the purpose if the special variable?

Am I missing something?

Regards

Seb
-- 
Emacs' AlsaPlayer - Music Without Jolts
Lightweight, full-featured and mindful of your idyllic happiness.
http://home.gna.org/eap




From sebyte at smolny.plus.com  Thu Oct  8 19:53:59 2009
From: sebyte at smolny.plus.com (Sebastian Tennant)
Date: Thu, 08 Oct 2009 19:53:59 +0000
Subject: [hunchentoot-devel] Default external format
References: <pr8xu1o8.fsf@vps203.linuxvps.org>
Message-ID: <ljjlu0fc.fsf@vps203.linuxvps.org>

Stop press!

It's not a hunchentoot issue.  It's a SLIME/SWANK issue.

I've set things up so that hunchentoot, then my acceptors, and then my handlers
are all loaded from my lisp implementation's init file.  

The problem occurs immediately after start-up (M-x slime), regardless of
whether my handler explicitly sets the output format or not, but if I then
manually evaluate the handler (M-x slime-eval-last-expression) and reload the
page in my browser the problem goes away.

Sorry for the noise.  

Seb
-- 
Emacs' AlsaPlayer - Music Without Jolts
Lightweight, full-featured and mindful of your idyllic happiness.
http://home.gna.org/eap




From edi at agharta.de  Thu Oct  8 23:14:12 2009
From: edi at agharta.de (Edi Weitz)
Date: Fri, 9 Oct 2009 01:14:12 +0200
Subject: [hunchentoot-devel] Default external format
In-Reply-To: <pr8xu1o8.fsf@vps203.linuxvps.org>
References: <pr8xu1o8.fsf@vps203.linuxvps.org>
Message-ID: <b56421a00910081614u34be2be7jfdf4ed361724a73c@mail.gmail.com>

Hi,

On Thu, Oct 8, 2009 at 9:27 PM, Sebastian Tennant
<sebyte at smolny.plus.com> wrote:

> I don't often see messages of thanks on open source software mailing lists, so,
> without wishing to sound obsequious, let me buck the trend by thanking Edi, and
> everone else, before and since, for their work on hunchentoot.

Thanks... :)

> I've found that setting this at the top level of cl-user:
>
> ?(setf tbnl:*hunchentoot-default-external-format* tbnl::+utf-8+)
>
> has no effect, other than preventing an error when a handler produces non-ascii
> text, i.e., the non-ascii text is garbled when displayed in the browser,
> despite including the line:
>
> ?(setf (tbnl:content-type*) "text/html; charset=utf-8")
>
> in the handler.
>
> The problem is solved by also including the line:
>
> ?(setf (tbnl:reply-external-format tbnl:*REPLY*) tbnl::+utf-8+)
>
> in the handler, so what then is the purpose if the special variable?

As explained in the documentation, the special variable
*HUNCHENTOOT-DEFAULT-EXTERNAL-FORMAT* is used when computing the
/request/ object.  As you said, it doesn't have an effect on the
reply.

The test suite which is delivered with Hunchentoot contains examples
for UTF-8 output.

HTH,
Edi.



From sebyte at smolny.plus.com  Fri Oct  9 09:54:38 2009
From: sebyte at smolny.plus.com (Sebastian Tennant)
Date: Fri, 09 Oct 2009 09:54:38 +0000
Subject: [hunchentoot-devel] Default external format
References: <pr8xu1o8.fsf@vps203.linuxvps.org>
	<b56421a00910081614u34be2be7jfdf4ed361724a73c@mail.gmail.com>
Message-ID: <ws34zych.fsf@vps203.linuxvps.org>

Quoth Edi Weitz <edi at agharta.de>:
> *HUNCHENTOOT-DEFAULT-EXTERNAL-FORMAT* is used when computing the
> /request/ object.  As you said, it doesn't have an effect on the
> reply.

Ah... I missed that.  Thanks for the clarification.

The need for a default encoding when computing the request object suggests to
me that there must be such things as badly formed requests, i.e., ones from
which the character encoding can't be reliably determined.?  If so, which
clients are the worst offenders, just out of interest?

> The test suite which is delivered with Hunchentoot contains examples
> for UTF-8 output.

Noted.

Unfortunately, I can't pin the problem I'm having down.  In my last post (which
began "Stop press!") I thought it must be a SWANK/SLIME issue, but I experience
the same weird behaviour if I run ccl from a shell.

In short, immediately after load'ing my handler via my init file at startup,
any non-ascii text in my handler is garbled in the browser.  If I then copy and
paste the handler into the REPL, i.e., re-evaluate it, the non-ascii text is
displayed correctly.  What on earth could be causing this?

I'm using my development box (CCL in OS X) at the moment.  I'm going to go and
test it on my production box (SBCL in Debian).  I don't know what else to try.

Seb
-- 
Emacs' AlsaPlayer - Music Without Jolts
Lightweight, full-featured and mindful of your idyllic happiness.
http://home.gna.org/eap




From edi at agharta.de  Fri Oct  9 10:53:57 2009
From: edi at agharta.de (Edi Weitz)
Date: Fri, 9 Oct 2009 12:53:57 +0200
Subject: [hunchentoot-devel] Default external format
In-Reply-To: <ws34zych.fsf@vps203.linuxvps.org>
References: <pr8xu1o8.fsf@vps203.linuxvps.org>
	<b56421a00910081614u34be2be7jfdf4ed361724a73c@mail.gmail.com>
	<ws34zych.fsf@vps203.linuxvps.org>
Message-ID: <b56421a00910090353r6a74792flef6120f7d6becd36@mail.gmail.com>

On Fri, Oct 9, 2009 at 11:54 AM, Sebastian Tennant
<sebyte at smolny.plus.com> wrote:

> The need for a default encoding when computing the request object suggests to
> me that there must be such things as badly formed requests, i.e., ones from
> which the character encoding can't be reliably determined.? ?If so, which
> clients are the worst offenders, just out of interest?

I'm not aware of specific offenders.  Clients /should/ indicate the
character encoding in the headers they send, so this is mainly a
safety measure.

If you want to experiment yourself, take a look at the "GET/POST
parameter handling with ... character set" tests in the Hunchentoot
distribution and look at the headers specific clients send.

> Unfortunately, I can't pin the problem I'm having down. ?In my last post (which
> began "Stop press!") I thought it must be a SWANK/SLIME issue, but I experience
> the same weird behaviour if I run ccl from a shell.
>
> In short, immediately after load'ing my handler via my init file at startup,
> any non-ascii text in my handler is garbled in the browser. ?If I then copy and
> paste the handler into the REPL, i.e., re-evaluate it, the non-ascii text is
> displayed correctly. ?What on earth could be causing this?
>
> I'm using my development box (CCL in OS X) at the moment. ?I'm going to go and
> test it on my production box (SBCL in Debian). ?I don't know what else to try.

I think you should first try to do this from the command line without
Emacs to see if the problem remains.  This very much (lacking a
detailed description) sounds like an Emacs problem to me.



From sebyte at smolny.plus.com  Fri Oct  9 23:48:59 2009
From: sebyte at smolny.plus.com (Sebastian Tennant)
Date: Fri, 09 Oct 2009 23:48:59 +0000
Subject: [hunchentoot-devel] Default external format
References: <pr8xu1o8.fsf@vps203.linuxvps.org>
	<b56421a00910081614u34be2be7jfdf4ed361724a73c@mail.gmail.com>
	<ws34zych.fsf@vps203.linuxvps.org>
	<b56421a00910090353r6a74792flef6120f7d6becd36@mail.gmail.com>
Message-ID: <bpkg6sd0.fsf@vps203.linuxvps.org>

Quoth Edi Weitz <edi at agharta.de>:
> I'm not aware of specific offenders.  Clients /should/ indicate the
> character encoding in the headers they send, so this is mainly a
> safety measure.

Understood.

> If you want to experiment yourself, take a look at the "GET/POST
> parameter handling with ... character set" tests in the Hunchentoot
> distribution and look at the headers specific clients send.

Noted.

> I think you should first try to do this from the command line without
> Emacs to see if the problem remains.  This very much (lacking a
> detailed description) sounds like an Emacs problem to me.

That's what I thought at first... but when I realised that the problem only
occurs at the load'ing stage, I realised that it has nothing to do with Emacs.
Using Emacs/SLIME/SWANK to re-evaluate the code just happened to fix it, but it
wasn't causing it.

Anyway, the problem doesn't occur on my production box (SBCL in Debian Lenny)
so it's not a major issue... something (the gods only know what) to do
with... something else!

Seb
-- 
Emacs' AlsaPlayer - Music Without Jolts
Lightweight, full-featured and mindful of your idyllic happiness.
http://home.gna.org/eap




From daniel at whitehouse.id.au  Sat Oct 10 10:44:03 2009
From: daniel at whitehouse.id.au (Daniel White)
Date: Sat, 10 Oct 2009 21:44:03 +1100
Subject: [hunchentoot-devel] Default external format
In-Reply-To: <ws34zych.fsf@vps203.linuxvps.org>
References: <pr8xu1o8.fsf@vps203.linuxvps.org>
	<b56421a00910081614u34be2be7jfdf4ed361724a73c@mail.gmail.com>
	<ws34zych.fsf@vps203.linuxvps.org>
Message-ID: <20091010214403.00c009cf@whitehouse.id.au>

On Fri, 09 Oct 2009 09:54:38 +0000
Sebastian Tennant <sebyte at smolny.plus.com> wrote:

> Unfortunately, I can't pin the problem I'm having down.  In my last post (which
> began "Stop press!") I thought it must be a SWANK/SLIME issue, but I experience
> the same weird behaviour if I run ccl from a shell.
> 
> In short, immediately after load'ing my handler via my init file at startup,
> any non-ascii text in my handler is garbled in the browser.  If I then copy and
> paste the handler into the REPL, i.e., re-evaluate it, the non-ascii text is
> displayed correctly.  What on earth could be causing this?

This sounds suspiciously like a problem we were having where the locale
wasn't properly set, resulting in SB-IMPL::*DEFAULT-EXTERNAL-FORMAT*
having a value that wasn't :UTF8.

-- 
Daniel White



From sebyte at smolny.plus.com  Sat Oct 10 11:32:34 2009
From: sebyte at smolny.plus.com (Sebastian Tennant)
Date: Sat, 10 Oct 2009 11:32:34 +0000
Subject: [hunchentoot-devel] Default external format
In-Reply-To: <20091010214403.00c009cf@whitehouse.id.au> (Daniel White's
	message of "Sat\, 10 Oct 2009 21\:44\:03 +1100")
References: <pr8xu1o8.fsf@vps203.linuxvps.org>
	<b56421a00910081614u34be2be7jfdf4ed361724a73c@mail.gmail.com>
	<ws34zych.fsf@vps203.linuxvps.org>
	<20091010214403.00c009cf@whitehouse.id.au>
Message-ID: <r5tbmqlp.fsf@vps203.linuxvps.org>

Quoth Daniel White <daniel at whitehouse.id.au>:
> On Fri, 09 Oct 2009 09:54:38 +0000
> Sebastian Tennant <sebyte at smolny.plus.com> wrote:
>
>> Unfortunately, I can't pin the problem I'm having down.  In my last post (which
>> began "Stop press!") I thought it must be a SWANK/SLIME issue, but I experience
>> the same weird behaviour if I run ccl from a shell.
>> 
>> In short, immediately after load'ing my handler via my init file at startup,
>> any non-ascii text in my handler is garbled in the browser.  If I then copy and
>> paste the handler into the REPL, i.e., re-evaluate it, the non-ascii text is
>> displayed correctly.  What on earth could be causing this?
>
> This sounds suspiciously like a problem we were having where the locale
> wasn't properly set, resulting in SB-IMPL::*DEFAULT-EXTERNAL-FORMAT*
> having a value that wasn't :UTF8.

Hmm, just checked the value of SB-IMPL::*DEFAULT-EXTERNAL-FORMAT* and it is
correctly set (by default, as I've done nothing to change it).

The problem only occurs on my CCL development box anyway.  I wonder what the
CCL equivalent of SB-IMPL::*DEFAULT-EXTERNAL-FORMAT* is?

Seb



From patrick.may at mac.com  Mon Oct 12 19:40:30 2009
From: patrick.may at mac.com (Patrick May)
Date: Mon, 12 Oct 2009 15:40:30 -0400
Subject: [hunchentoot-devel] Default external format
In-Reply-To: <pr8xu1o8.fsf@vps203.linuxvps.org>
References: <pr8xu1o8.fsf@vps203.linuxvps.org>
Message-ID: <B96BA3FA-BDA6-4216-A175-BBE1C1E29C16@mac.com>

On Oct 8, 2009, at 3:27 PM, Sebastian Tennant wrote:
> Hi list,
>
> I don't often see messages of thanks on open source software mailing  
> lists, so,
> without wishing to sound obsequious, let me buck the trend by  
> thanking Edi, and
> everone else, before and since, for their work on hunchentoot.

	+1.  Great software, much appreciated.

Regards,

Patrick




From zaries at global.co.za  Wed Oct 14 12:33:44 2009
From: zaries at global.co.za (Phil Marneweck)
Date: Wed, 14 Oct 2009 14:33:44 +0200
Subject: [hunchentoot-devel] acceptor-names not found
Message-ID: <1255523624.4114.6.camel@scatha>

Has any body tried to use acceptor-names in hunchentoot
define-easy-handler? 

I can only get the easy-handler to find the acceptor-name if I change 

(find (acceptor-name *acceptor*) acceptor-names :test #'eq))

to

(find (acceptor-name *acceptor*) acceptor-names :test #'equal))


In the following function. 

(defun dispatch-easy-handlers (request)
  "This is a dispatcher which returns the appropriate handler
defined with DEFINE-EASY-HANDLER, if there is one."
  (loop for (uri acceptor-names easy-handler) in *easy-handler-alist*
        when (and (or (eq acceptor-names t)
                      (find (acceptor-name *acceptor*) acceptor-names :test #'eq))
			....



As far as I have seen in my tests acceptor-names have to be strings(sequences) so changing eq to equal makes sense...

Or am I smoking my socks again?






From sebyte at smolny.plus.com  Wed Oct 14 12:47:13 2009
From: sebyte at smolny.plus.com (Sebastian Tennant)
Date: Wed, 14 Oct 2009 12:47:13 +0000
Subject: [hunchentoot-devel] Customizing acceptor behaviour
Message-ID: <7huyjg6m.fsf@vps203.linuxvps.org>

Hi there,

I've managed to set up two acceptors which use different dispatch tables and
write to different message log files by using packages and passing modified
copies of LOG-MESSAGE-TO-FILE and LIST-REQUEST-DISPATCHER as keyword args when
instantiating each acceptor (within each package).

It works but there is a lot of code duplication going on so I decided to try
and creating a third package (maytal) which does essentially the same thing in
an abstracted way by subclassing TBNL:ACCEPTOR.

I should point out that If I'm barking up the wrong tree entirely, it's because
I'm new to CLOS (and relatively new to OOP in general).

In short, I'm trying to create a package (maytal) which I can use in other
packages like so:

 ;; set up and enter development environment package
 (in-package :cl-user)
 (defpackage "DEV-ENV" (:use :cl))
 (in-package :dev-env)

 ;; dev-env::*dispatch-table*
 (defvar *dispatch-table* '())

 ;; instantiate dev-env::*acceptor*
 (defvar *acceptor* (make-instance 'maytal::acceptor
                                   :port 49154
                                   :msg-log-file "./messages/dev.log"
                                   :dispatch-table *dispatch-table*))

 (tbnl:start *acceptor*)
 (msg 'info "DEV-ENV::*ACCEPTOR* started on port 49154")



Here's my first stab at creating maytal:

 (in-package :cl-user)
 (defpackage "MAYTAL" (:use :cl))
 (in-package :maytal)

 (defclass acceptor (tbnl:acceptor)
   ((msg-log-file :initarg :msg-log-file)
    (dispatch-table :initarg :dispatch-table)))

 (defmethod initialize-instance :after ((a acceptor) &key)
   ;; prepare local environment for closures
   (let ((mlf (slot-value a 'msg-log-file))
	 (dt (slot-value a 'dispatch-table)))

     ;; handy (i.e., short-name) message log function based on tbnl:log-message-to-file
     (defun msg (log-level format-string &rest format-arguments)
       (tbnl::with-log-file
        (stream mlf (tbnl::make-lock (symbol-name (gensym))))
        (format stream "[~A~@[ [~A]~]] ~?~%" (tbnl::iso-time) log-level
                format-string format-arguments)))

     (setf (slot-value a 'tbnl::message-logger) 'msg)

     ;; annonymous request dispatcher function based on tbnl:list-request-dispatcher but
     ;; which uses a locally defined dispatch table variable
     (setf (slot-value a 'tbnl::request-dispatcher)
	   (lambda (request)
	     (loop for dispatcher in dt
		   for action = (funcall dispatcher request)
		   when action return (funcall action)
		     finally (setf (tbnl:return-code tbnl:*reply*)
				   tbnl:+http-not-found+)))
     ))

Needless to say it doesn't work. The function 'msg' is defined in the maytal package
rather than in the package which is current when an instance of maytal::acceptor is
created (thus defeating the whole purpose of my efforts), and although the request
dispatcher functions in different packages appear to use different dispatch tables, they
don't actually work!

 ;;; (in-package :dev-env)
 (msg 'info "Acceptor ITI-DEV::*ACCEPTOR* started on port 49154")
 ;;; => Undefined function MSG called with arguments [...]                                                                           
 (tbnl::acceptor-message-logger *acceptor*)
 ;;; => MAYTAL::MSG

 (tbnl::acceptor-request-dispatcher *acceptor*)
 ;;; => #<CCL:COMPILED-LEXICAL-CLOSURE (:INTERNAL (INITIALIZE-INSTANCE :AFTER (MAYTAL::ACCEPTOR))) #x91D16C6>                        
Any and all help very much appreciated.

Regards,

Seb
-- 
Emacs' AlsaPlayer - Music Without Jolts
Lightweight, full-featured and mindful of your idyllic happiness.
http://home.gna.org/eap




From edi at agharta.de  Wed Oct 14 21:31:13 2009
From: edi at agharta.de (Edi Weitz)
Date: Wed, 14 Oct 2009 23:31:13 +0200
Subject: [hunchentoot-devel] Customizing acceptor behaviour
In-Reply-To: <7huyjg6m.fsf@vps203.linuxvps.org>
References: <7huyjg6m.fsf@vps203.linuxvps.org>
Message-ID: <b56421a00910141431q24be2cf8sda900f32b6e30d08@mail.gmail.com>

On Wed, Oct 14, 2009 at 2:47 PM, Sebastian Tennant
<sebyte at smolny.plus.com> wrote:

> I've managed to set up two acceptors which use different dispatch tables and
> write to different message log files by using packages [...]

>From taking a quick glance at what you wrote here my suspicion is that
you have the wrong concept of Lisp packages.  I'd suggest that you
take a look at this

  http://weitz.de/packages.html

and then for example read the chapter about packages in Peter Seibel's book.

HTH,
Edi.



From edi at agharta.de  Wed Oct 14 21:37:58 2009
From: edi at agharta.de (Edi Weitz)
Date: Wed, 14 Oct 2009 23:37:58 +0200
Subject: [hunchentoot-devel] Small patch for LispWorks 6 beta
In-Reply-To: <87tyyhbrif.fsf@galileo.bitart.cc>
References: <873a64ny5s.fsf@galileo.bitart.cc>
	<fd2982320909301604p1a2a8387ke8dd5839202bc2a4@mail.gmail.com>
	<87ws3fhruu.fsf@galileo.bitart.cc>
	<b56421a00910011408s606f05d4s909469b6357f1635@mail.gmail.com>
	<87tyyhbrif.fsf@galileo.bitart.cc>
Message-ID: <b56421a00910141437n2d7da15aldd7b155fa648553f@mail.gmail.com>

Thanks, applied to the dev version.

Edi.

On Fri, Oct 2, 2009 at 8:05 PM, Nico de Jager <ndj at bitart.cc> wrote:
> Edi Weitz <edi at agharta.de> writes:
>
>> On Thu, Oct 1, 2009 at 8:49 PM, Nico de Jager <ndj at bitart.cc> wrote:
>>
>>> No, it is as intended. Please correct me if I am having a brain fart.
>>
>> My bad. ?I didn't look closely enough.
>>
>>> The first patch I sent to Edi privately, was as the one at the
>>> bottom. But isn't
>>>
>>> #+:lispworks4 ?== ?#-(or :lispworks5 :lispworks6)
>>> and
>>> #-:lispworks4 ?== ?#+(or :lispworks5 :lispworks6)
>>>
>>> when we are only considering version 4, 5 and 6? In fact, the patch at
>>> the top is better, since when LispWorks 7.x comes out the patch above
>>> will already work as it covers versions 4 and higher, but the patch
>>> below will have to be amended, since it only covers version 4, 5 and
>>> 6. Which one is clearer, is subjective - I like the one at the top
>>> because the exceptions is specifically for LispWorks4 and for the reason
>>> described in the previous sentence.
>>
>> What I don't like about this is that it doesn't take LW3 into account... :)
>>
>> Only half joking, really. ?Starting with LW4 seems a rather arbitrary
>> assumption to me although the code very likely won't work with LW3
>> anyway, but the code isn't self-documenting anymore. ?#-:lispworks4
>> says "for all except LW4" while you actually wanted to say "for LW5
>> and LW6 and maybe LW7 as well".
>
> But..., hmm..., ok. :-)
>
>
>>> B.t.w. the double #+:lispworks5 #+:lispworks5 in the original code is a
>>> (harmless) mistake, correct?
>>
>> No, it's on purpose. ?It affects the /two/ forms following it and your
>> patch must also take care of two forms.
>
> I see - thanks Edi. Back to the CLHS then...
>
> Below, is another attempt.
>
> Regards.
> Nico
>
>
> $ diff -u lispworks.lisp lispworks.lisp_patched3
> --- lispworks.lisp ? ? ?2009-02-17 00:14:24.000000000 +0200
> +++ lispworks.lisp_patched3 ? ? 2009-10-02 20:03:58.986727798 +0200
> @@ -90,14 +90,14 @@
> ?(defun make-socket-stream (socket acceptor)
> ? "Returns a stream for the socket SOCKET. ?The ACCEPTOR argument is
> ?used to set the timeouts."
> - ?#-:lispworks5
> + ?#-(or :lispworks5 :lispworks6)
> ? (when (acceptor-write-timeout acceptor)
> ? ? (parameter-error "You need LispWorks 5 or higher for write timeouts."))
> ? (make-instance 'comm:socket-stream
> ? ? ? ? ? ? ? ? ?:socket socket
> ? ? ? ? ? ? ? ? ?:direction :io
> ? ? ? ? ? ? ? ? ?:read-timeout (acceptor-read-timeout acceptor)
> - ? ? ? ? ? ? ? ? #+:lispworks5 #+:lispworks5
> + ? ? ? ? ? ? ? ? #+(or :lispworks5 :lispworks6) #+(or :lispworks5 :lispworks6)
> ? ? ? ? ? ? ? ? ?:write-timeout (acceptor-write-timeout acceptor)
> ? ? ? ? ? ? ? ? ?:element-type 'octet))
>
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel



From edi at agharta.de  Wed Oct 14 21:43:19 2009
From: edi at agharta.de (Edi Weitz)
Date: Wed, 14 Oct 2009 23:43:19 +0200
Subject: [hunchentoot-devel] acceptor-names not found
In-Reply-To: <1255523624.4114.6.camel@scatha>
References: <1255523624.4114.6.camel@scatha>
Message-ID: <b56421a00910141443l767b969eu2df0be1504ac26a@mail.gmail.com>

On Wed, Oct 14, 2009 at 2:33 PM, Phil Marneweck <zaries at global.co.za> wrote:

> As far as I have seen in my tests acceptor-names have to be strings(sequences) so changing eq to equal makes sense...

Maybe I'm missing something, but why do you think they have to be strings?

Edi.



From sebyte at smolny.plus.com  Thu Oct 15 10:13:35 2009
From: sebyte at smolny.plus.com (Sebastian Tennant)
Date: Thu, 15 Oct 2009 10:13:35 +0000
Subject: [hunchentoot-devel] Customizing acceptor behaviour
References: <7huyjg6m.fsf@vps203.linuxvps.org>
	<b56421a00910141431q24be2cf8sda900f32b6e30d08@mail.gmail.com>
Message-ID: <r5t52cds.fsf@vps203.linuxvps.org>

Hi Edi,

Thanks for your reply.

Quoth Edi Weitz <edi at agharta.de>:
> From taking a quick glance at what you wrote here my suspicion is that
> you have the wrong concept of Lisp packages.  I'd suggest that you
> take a look at this
>
>   http://weitz.de/packages.html
>
> and then for example read the chapter about packages in Peter Seibel's book.

I've read this chapter and I've also read Erann Gat's 'Complete Idiot's Guide
to Common Lisp Packages'.  Gat goes into considerably greater depth than Seibel
and I think it's fair to say that I do understand packages; namespaces
respected by the Lisp reader, nothing more.

Everything I'm trying to do is in attempt to make it quick and easy to create
development and production environments served by hunchentoot in a single Lisp
image.

I was trying to subclass ACCEPTOR so that I can create them like so:

 (defvar *dispatch-table#1* '())
 (make-instance 'my-subclassed-acceptor :port 1234
                                        :msg-log-file "~/htoot-message-file#1.log"
                                        :dispatch-table *dispatch-table#1*)

 Making an instance of my-subclassed-acceptor should also define a function
 'msg' which writes to the log file specified.

I was then attempting to put the code that implements this subclass in its own
package so that it can easily be use'd in other packages.

You have designed hunchentoot with the ability to create multiple acceptors,
each listening on a different port.  I am simply trying to extend that
spearation so that each acceptor can be configured to use its own dispatch
table and write to its own message log file.

Seb
-- 
Emacs' AlsaPlayer - Music Without Jolts
Lightweight, full-featured and mindful of your idyllic happiness.
http://home.gna.org/eap




From stoye at stoye.com  Thu Oct 15 12:30:05 2009
From: stoye at stoye.com (R.Stoye)
Date: Thu, 15 Oct 2009 14:30:05 +0200
Subject: [hunchentoot-devel] Customizing acceptor behaviour
In-Reply-To: <r5t52cds.fsf@vps203.linuxvps.org>
References: <7huyjg6m.fsf@vps203.linuxvps.org>
	<b56421a00910141431q24be2cf8sda900f32b6e30d08@mail.gmail.com>
	<r5t52cds.fsf@vps203.linuxvps.org>
Message-ID: <69409B94-918F-4B53-978C-ED116E1D1BD9@stoye.com>

Another approach is to add an dispachtable slot to an customized  
acceptor class (as it was before Hunchentoot version 1.0):

(in-package :hunchentoot)

(defun pre1-list-request-dispatcher (request)
   (loop for dispatcher in (acceptor-dispatch-table *acceptor*)
         for action = (funcall dispatcher request)
         when action return (funcall action)
         finally (setf (return-code *reply*) +http-not-found+)))


(defclass pre1-acceptor (acceptor)
   ((pre1-dispatch-table :initarg :dispatch-table
			:accessor acceptor-dispatch-table))
   (:default-initargs
    :request-dispatcher #'pre1-list-request-dispatcher
     :dispatch-table nil))

;; (setf *myserver1* (make-instance 'pre1-acceptor :port 42001))
;; (setf (acceptor-dispatch-table *myserver1*)  (list (create-prefix- 
dispatcher "/mypage1.html" #'mypage1)))




From christoph.senjak at googlemail.com  Fri Oct 16 18:10:09 2009
From: christoph.senjak at googlemail.com (Christoph Senjak)
Date: Fri, 16 Oct 2009 20:10:09 +0200
Subject: [hunchentoot-devel] Best way to run Hunchentoot on Port 80,
	Proxy-Module for Hunchentoot
Message-ID: <33ed8ce70910161110t57b38a50sf24023397877a5b6@mail.gmail.com>

Hello.

As I am really annoyed by the confusing configuration-"possibilities"
of apache, and as lighttpd doesnt support what I want to do in its
stable release, I want to run hunchentoot in the first place. However,
there are two problems:

At first, I cannot run a usermode-process listening on port 80. I am
using sbcl, so I could use sb-posix:setuid after starting hunchentoot
and gaining port 80, removing root-privileges. Or I could forward port
80 to port 8000 via firewall policies.

I would prefer the first possibility. The question is, if there is
anything millitating against starting hunchentoot as root and then
using setuid. I.e. any security issues that could result from it,
anything that maybe wont work, etc.

Another thing is the question if there is some proxy- or
passthrough-module for hunchentoot. I still have some php-pages I want
to host (even though I will use lighttpd rather than apache for this),
and would therefore need to pass them to another server in the
background.

Regards,
Christoph Senjak



From edi at agharta.de  Fri Oct 16 21:14:43 2009
From: edi at agharta.de (Edi Weitz)
Date: Fri, 16 Oct 2009 23:14:43 +0200
Subject: [hunchentoot-devel] Best way to run Hunchentoot on Port 80,
	Proxy-Module for Hunchentoot
In-Reply-To: <33ed8ce70910161110t57b38a50sf24023397877a5b6@mail.gmail.com>
References: <33ed8ce70910161110t57b38a50sf24023397877a5b6@mail.gmail.com>
Message-ID: <b56421a00910161414y3714ff79pf55696770312a729@mail.gmail.com>

On Fri, Oct 16, 2009 at 8:10 PM, Christoph Senjak
<christoph.senjak at googlemail.com> wrote:

> As I am really annoyed by the confusing configuration-"possibilities"
> of apache, and as lighttpd doesnt support what I want to do in its
> stable release, I want to run hunchentoot in the first place. However,
> there are two problems:
>
> At first, I cannot run a usermode-process listening on port 80. I am
> using sbcl, so I could use sb-posix:setuid after starting hunchentoot
> and gaining port 80, removing root-privileges. Or I could forward port
> 80 to port 8000 via firewall policies.
>
> I would prefer the first possibility. The question is, if there is
> anything millitating against starting hunchentoot as root and then
> using setuid. I.e. any security issues that could result from it,
> anything that maybe wont work, etc.

I've done that a couple of times, but mainly for testing purposes.
I'm not aware of any problems, but maybe others are.

> Another thing is the question if there is some proxy- or
> passthrough-module for hunchentoot. I still have some php-pages I want
> to host (even though I will use lighttpd rather than apache for this),
> and would therefore need to pass them to another server in the
> background.

I don't know of any such module.  It'd be nice to have, though... :)



From archimag at gmail.com  Fri Oct 16 21:49:13 2009
From: archimag at gmail.com (Andrey Moskvitin)
Date: Sat, 17 Oct 2009 01:49:13 +0400
Subject: [hunchentoot-devel] Best way to run Hunchentoot on Port 80,
	Proxy-Module for Hunchentoot
In-Reply-To: <33ed8ce70910161110t57b38a50sf24023397877a5b6@mail.gmail.com>
References: <33ed8ce70910161110t57b38a50sf24023397877a5b6@mail.gmail.com>
Message-ID: <e0c33b910910161449k2cbfaae6g93057729ea1cb3d8@mail.gmail.com>

> I am using sbcl, so I could use sb-posix:setuid after starting hunchentoot
> and gaining port 80, removing root-privileges.

(sb-posix::define-call "initgroups" int minusp (user c-string) (group
sb-posix::gid-t))
(sb-posix::define-call "prctl" int minusp (option int) (arg int))
(sb-posix:prctl +PR_SET_KEEPCAPS+ 1)

(sb-posix:setresgid gid gid gid)
(sb-posix:initgroups name gid)
(sb-posix:setresuid uid uid uid))

(load-shared-object (find-if #'probe-file
                             '("/lib/libcap.so.2" "/lib/libcap.so")))

(sb-posix::define-call "cap_from_text" (* char) null-alien (text c-string))
(sb-posix::define-call "cap_set_proc" int minusp (cap_p (* char)))
(sb-posix::define-call "cap_free" int minusp (cap_p (* char)))

(let ((cap_p (sb-posix:cap-from-text "CAP_NET_BIND_SERVICE=ep")))
  (sb-posix:cap-set-proc cap_p)
  (sb-posix:cap-free cap_p))

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

I use this code for run http://lisper.ru/  Required libcap2. Tested on
Debian and Gentoo.

Full script: http://github.com/archimag/rulisp/blob/devel/rulisp-daemon.lisp
<http://lisper.ru/apps/format/15>
Andrey

2009/10/16 Christoph Senjak <christoph.senjak at googlemail.com>

> Hello.
>
> As I am really annoyed by the confusing configuration-"possibilities"
> of apache, and as lighttpd doesnt support what I want to do in its
> stable release, I want to run hunchentoot in the first place. However,
> there are two problems:
>
> At first, I cannot run a usermode-process listening on port 80. I am
> using sbcl, so I could use sb-posix:setuid after starting hunchentoot
> and gaining port 80, removing root-privileges. Or I could forward port
> 80 to port 8000 via firewall policies.
>
> I would prefer the first possibility. The question is, if there is
> anything millitating against starting hunchentoot as root and then
> using setuid. I.e. any security issues that could result from it,
> anything that maybe wont work, etc.
>
> Another thing is the question if there is some proxy- or
> passthrough-module for hunchentoot. I still have some php-pages I want
> to host (even though I will use lighttpd rather than apache for this),
> and would therefore need to pass them to another server in the
> background.
>
> Regards,
> Christoph Senjak
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20091017/7ad660f3/attachment.html>

From sky at viridian-project.de  Sat Oct 17 08:08:27 2009
From: sky at viridian-project.de (Leslie P. Polzer)
Date: Sat, 17 Oct 2009 10:08:27 +0200 (CEST)
Subject: [hunchentoot-devel] Best way to run Hunchentoot on Port 80,
 Proxy-Module for Hunchentoot
In-Reply-To: <33ed8ce70910161110t57b38a50sf24023397877a5b6@mail.gmail.com>
References: <33ed8ce70910161110t57b38a50sf24023397877a5b6@mail.gmail.com>
Message-ID: <258dd0ef48e1f6bd99b08445a678e704.squirrel@mail.stardawn.org>


Christoph Senjak wrote:

> Another thing is the question if there is some proxy- or
> passthrough-module for hunchentoot. I still have some php-pages I want
> to host (even though I will use lighttpd rather than apache for this),
> and would therefore need to pass them to another server in the
> background.

That shouldn't be hard to code. There is also the possibility to use
CGI with Hunchentoot and PHP for that, see:

  http://cyrusharmon.org/projects?project=hunchentoot-cgi

 Best,

   Leslie

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




From christoph.senjak at googlemail.com  Sat Oct 17 10:19:18 2009
From: christoph.senjak at googlemail.com (Christoph Senjak)
Date: Sat, 17 Oct 2009 12:19:18 +0200
Subject: [hunchentoot-devel] Best way to run Hunchentoot on Port 80,
	Proxy-Module for Hunchentoot
In-Reply-To: <258dd0ef48e1f6bd99b08445a678e704.squirrel@mail.stardawn.org>
References: <33ed8ce70910161110t57b38a50sf24023397877a5b6@mail.gmail.com>
	<258dd0ef48e1f6bd99b08445a678e704.squirrel@mail.stardawn.org>
Message-ID: <33ed8ce70910170319k4d2adb90n1d04d933cf88078e@mail.gmail.com>

2009/10/17 Leslie P. Polzer <sky at viridian-project.de>:
>
> Christoph Senjak wrote:
>
>> Another thing is the question if there is some proxy- or
>> passthrough-module for hunchentoot. I still have some php-pages I want
>> to host (even though I will use lighttpd rather than apache for this),
>> and would therefore need to pass them to another server in the
>> background.
>
> That shouldn't be hard to code. There is also the possibility to use
> CGI with Hunchentoot and PHP for that, see:
>
> ?http://cyrusharmon.org/projects?project=hunchentoot-cgi
>
> ?Best,
>
Ah nice. Actually, yesterday I was reading the CGI-Specification to
code exactly this. Thank you. I will try to use php-cgi. This is the
default fastcgi-interpreter, but it also has a cgi-interface.

Regards
Christoph



From zaries at global.co.za  Sat Oct 17 10:53:12 2009
From: zaries at global.co.za (Phil Marneweck)
Date: Sat, 17 Oct 2009 12:53:12 +0200
Subject: [hunchentoot-devel] acceptor-names not found
In-Reply-To: <b56421a00910141443l767b969eu2df0be1504ac26a@mail.gmail.com>
References: <1255523624.4114.6.camel@scatha>
	<b56421a00910141443l767b969eu2df0be1504ac26a@mail.gmail.com>
Message-ID: <1255776792.2968.43.camel@scatha>

Hi

Some where along the line when I tried to use acceptor-names for the
first time I got a not of type sequence error and there I went and made
the assumption that they had to be strings. I most likely fluffed
something some where along the line.

I was wondering would it make sense to be able to to register the same
uri more than once with *easy-handler-alist*. Then using the uri
acceptor-names combination to select the appropriate function to serve
the request. Or is there another mechanism to be able to re-use a uri.

Regards
Phil






On Wed, 2009-10-14 at 23:43 +0200, Edi Weitz wrote:
> On Wed, Oct 14, 2009 at 2:33 PM, Phil Marneweck <zaries at global.co.za> wrote:
> 
> > As far as I have seen in my tests acceptor-names have to be strings(sequences) so changing eq to equal makes sense...
> 
> Maybe I'm missing something, but why do you think they have to be strings?
> 
> Edi.
> 
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel




From christoph.senjak at googlemail.com  Sun Oct 18 03:03:52 2009
From: christoph.senjak at googlemail.com (Christoph Senjak)
Date: Sun, 18 Oct 2009 05:03:52 +0200
Subject: [hunchentoot-devel] Best way to run Hunchentoot on Port 80,
	Proxy-Module for Hunchentoot
In-Reply-To: <33ed8ce70910170319k4d2adb90n1d04d933cf88078e@mail.gmail.com>
References: <33ed8ce70910161110t57b38a50sf24023397877a5b6@mail.gmail.com>
	<258dd0ef48e1f6bd99b08445a678e704.squirrel@mail.stardawn.org>
	<33ed8ce70910170319k4d2adb90n1d04d933cf88078e@mail.gmail.com>
Message-ID: <33ed8ce70910172003ub08f789r2cd2407e2a43cbcf@mail.gmail.com>

Hello again.

>> That shouldn't be hard to code. There is also the possibility to use
>> CGI with Hunchentoot and PHP for that, see:
>>
>> ?http://cyrusharmon.org/projects?project=hunchentoot-cgi
>>
>> ?Best,
>>
> Ah nice. Actually, yesterday I was reading the CGI-Specification to
> code exactly this. Thank you. I will try to use php-cgi. This is the
> default fastcgi-interpreter, but it also has a cgi-interface.

Well, I had to add SCRIPT_FILENAME to the environment-variables that
are passed to the CGI-Scripts to be able to run php-scripts (it took
me a day to find this documented - google loves to list php-tutorials
with no helpful content ...). Now I can run them - sort of. But seems
like the session-management somehow doesnt work. I also added a line

("HTTP_COOKIE" . ,(let ((r ""))
             (dolist (cookie (hunchentoot:cookies-in*))
               (setf r (concatenate 'string (car cookie) "=" (cdr
cookie) ";" r)))
             r))

which adds the environmental-variable HTTP_COOKIE and should be
correct (I couldnt find out whether the cookies should be separated
via a semicolon or something else, but seems like semicolon is right,
nor could I find out whether to encode these cookies somehow before
putting them i this variable, but seems like none of the cookies I saw
has any special characters). There seems to be a cookie sent to the
php-script. When adding a (format t r), I see a string of the form
sid=<random-sid>. So the php-engine /should/ know about the cookies.
Still, it doesnt work. Could it be that hunchentoot doesnt list some
cookies in (hunchentoot:cookies-in*), or removes outgoing cookies?

Or any Ideas what else I have to set?

Regards,
Christoph



From sky at viridian-project.de  Sun Oct 18 09:28:54 2009
From: sky at viridian-project.de (Leslie P. Polzer)
Date: Sun, 18 Oct 2009 11:28:54 +0200 (CEST)
Subject: [hunchentoot-devel] Best way to run Hunchentoot on Port 80,
 Proxy-Module for Hunchentoot
In-Reply-To: <33ed8ce70910172003ub08f789r2cd2407e2a43cbcf@mail.gmail.com>
References: <33ed8ce70910161110t57b38a50sf24023397877a5b6@mail.gmail.com>
	<258dd0ef48e1f6bd99b08445a678e704.squirrel@mail.stardawn.org>
	<33ed8ce70910170319k4d2adb90n1d04d933cf88078e@mail.gmail.com>
	<33ed8ce70910172003ub08f789r2cd2407e2a43cbcf@mail.gmail.com>
Message-ID: <82138f5824bdac3bb80b564f26de1f44.squirrel@mail.stardawn.org>


Hi Christoph,

> - google loves to list php-tutorials with no helpful content ...).

That's probably because there are a lot of beginner tutorials for PHP,
and hardly any serious stuff. ;)


> Now I can run them - sort of. But seems like the session-management
> somehow doesnt work. I also added a line
>
> ("HTTP_COOKIE" . ,(let ((r ""))
>              (dolist (cookie (hunchentoot:cookies-in*))
>                (setf r (concatenate 'string (car cookie) "=" (cdr
> cookie) ";" r)))
>              r))

Side note: you probably want to use FORMAT or REDUCE here.


> which adds the environmental-variable HTTP_COOKIE and should be
> correct (I couldnt find out whether the cookies should be separated
> via a semicolon or something else, but seems like semicolon is right,
> nor could I find out whether to encode these cookies somehow before
> putting them i this variable, but seems like none of the cookies I saw
> has any special characters). There seems to be a cookie sent to the
> php-script. When adding a (format t r), I see a string of the form
> sid=<random-sid>. So the php-engine /should/ know about the cookies.

IIRC sid is set by Hunchentoot and PHP's session cookie is named
PHPSESSID by default.


> Still, it doesnt work. Could it be that hunchentoot doesnt list some
> cookies in (hunchentoot:cookies-in*), or removes outgoing cookies?

Unlikely.


> Or any Ideas what else I have to set?

You need to do some comparative debugging with Apache/PHP-CGI and
Hunchentoot/PHP-CGI, since Apache is supposed to do the right thing.

Have a simple PHP script at the other end that lists the contents
of HTTP_COOKIE.

  Leslie

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




From sebyte at smolny.plus.com  Sun Oct 18 16:23:27 2009
From: sebyte at smolny.plus.com (Sebastian Tennant)
Date: Sun, 18 Oct 2009 16:23:27 +0000
Subject: [hunchentoot-devel] Customizing acceptor behaviour
References: <7huyjg6m.fsf@vps203.linuxvps.org>
	<b56421a00910141431q24be2cf8sda900f32b6e30d08@mail.gmail.com>
	<r5t52cds.fsf@vps203.linuxvps.org>
	<69409B94-918F-4B53-978C-ED116E1D1BD9@stoye.com>
Message-ID: <4opwbri8.fsf@vps203.linuxvps.org>

Quoth "R.Stoye" <stoye at stoye.com>:
> Another approach is to add an dispachtable slot to an customized  
> acceptor class (as it was before Hunchentoot version 1.0):

Thanks for your suggestion.  Noted and understood.  (In fact I had already done
something very similar).

My claim (in an earlier thread) that I understood Common Lisp packages was
true, but I realise now that I didn't quite understand how they're used in real
world applications.

For some reason, I thought it would be better not to 'pollute' the hunchentoot
namespace with my own subclasses e.t.c., hence my attempt to subclass the
hunchentoot acceptor class from within a separate namespace/package; maytal.  I
realise now that this is an almost unworkable and entirely unnecessary
practice.

Seb
-- 
Emacs' AlsaPlayer - Music Without Jolts
Lightweight, full-featured and mindful of your idyllic happiness.
http://home.gna.org/eap




From sky at viridian-project.de  Mon Oct 19 07:20:18 2009
From: sky at viridian-project.de (Leslie P. Polzer)
Date: Mon, 19 Oct 2009 09:20:18 +0200 (CEST)
Subject: [hunchentoot-devel] Customizing acceptor behaviour
In-Reply-To: <4opwbri8.fsf@vps203.linuxvps.org>
References: <7huyjg6m.fsf@vps203.linuxvps.org>
	<b56421a00910141431q24be2cf8sda900f32b6e30d08@mail.gmail.com>
	<r5t52cds.fsf@vps203.linuxvps.org>
	<69409B94-918F-4B53-978C-ED116E1D1BD9@stoye.com>
	<4opwbri8.fsf@vps203.linuxvps.org>
Message-ID: <6629d8e08a6d4bf521a5d23d35989743.squirrel@mail.stardawn.org>


Sebastian Tennant wrote:

> For some reason, I thought it would be better not to 'pollute' the hunchentoot
> namespace with my own subclasses e.t.c., hence my attempt to subclass the
> hunchentoot acceptor class from within a separate namespace/package; maytal.  I
> realise now that this is an almost unworkable and entirely unnecessary
> practice.

Well, you shouldn't place your own symbols (~subclasses) into the Hunchentoot
package indeed.

  Leslie

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




From stoye at stoye.com  Mon Oct 19 08:18:56 2009
From: stoye at stoye.com (R.Stoye)
Date: Mon, 19 Oct 2009 10:18:56 +0200
Subject: [hunchentoot-devel] Customizing acceptor behaviour
In-Reply-To: <4opwbri8.fsf@vps203.linuxvps.org>
References: <7huyjg6m.fsf@vps203.linuxvps.org>
	<b56421a00910141431q24be2cf8sda900f32b6e30d08@mail.gmail.com>
	<r5t52cds.fsf@vps203.linuxvps.org>
	<69409B94-918F-4B53-978C-ED116E1D1BD9@stoye.com>
	<4opwbri8.fsf@vps203.linuxvps.org>
Message-ID: <B784C3D7-D71E-41DE-8143-54961B7B3B5D@stoye.com>


Am 18.10.2009 um 18:23 schrieb Sebastian Tennant:

> I thought it would be better not to 'pollute' the hunchentoot

indeed i put the code out of context, the actual code uses its own  
package

(defpackage hunchentoot-addon
   (:use :cl :hunchentoot))

(in-package :hunchentoot-addon)



Ralf



From edi at agharta.de  Mon Oct 19 09:39:46 2009
From: edi at agharta.de (Edi Weitz)
Date: Mon, 19 Oct 2009 11:39:46 +0200
Subject: [hunchentoot-devel] Best way to run Hunchentoot on Port 80,
	Proxy-Module for Hunchentoot
In-Reply-To: <33ed8ce70910172003ub08f789r2cd2407e2a43cbcf@mail.gmail.com>
References: <33ed8ce70910161110t57b38a50sf24023397877a5b6@mail.gmail.com>
	<258dd0ef48e1f6bd99b08445a678e704.squirrel@mail.stardawn.org>
	<33ed8ce70910170319k4d2adb90n1d04d933cf88078e@mail.gmail.com>
	<33ed8ce70910172003ub08f789r2cd2407e2a43cbcf@mail.gmail.com>
Message-ID: <b56421a00910190239y6b999481t52133e78a005b63f@mail.gmail.com>

On Sun, Oct 18, 2009 at 5:03 AM, Christoph Senjak
<christoph.senjak at googlemail.com> wrote:

> Well, I had to add SCRIPT_FILENAME to the environment-variables that
> are passed to the CGI-Scripts to be able to run php-scripts (it took
> me a day to find this documented - google loves to list php-tutorials
> with no helpful content ...). Now I can run them - sort of. But seems
> like the session-management somehow doesnt work. I also added a line
>
> ("HTTP_COOKIE" . ,(let ((r ""))
> ? ? ? ? ? ? (dolist (cookie (hunchentoot:cookies-in*))
> ? ? ? ? ? ? ? (setf r (concatenate 'string (car cookie) "=" (cdr
> cookie) ";" r)))
> ? ? ? ? ? ? r))
>
> which adds the environmental-variable HTTP_COOKIE and should be
> correct (I couldnt find out whether the cookies should be separated
> via a semicolon or something else, but seems like semicolon is right,
> nor could I find out whether to encode these cookies somehow before
> putting them i this variable, but seems like none of the cookies I saw
> has any special characters).

There are RFCs where this is documented.  You should either send
multiple cookie headers for multiple cookies or separate them with
commas.  Note that some servers violate the RFCs, though.  See current
discussion on Drakma mailing list.

And, yes, cookie should be encoded as well.  Look at Hunchentoot's source code.

> There seems to be a cookie sent to the
> php-script. When adding a (format t r), I see a string of the form
> sid=<random-sid>. So the php-engine /should/ know about the cookies.
> Still, it doesnt work. Could it be that hunchentoot doesnt list some
> cookies in (hunchentoot:cookies-in*), or removes outgoing cookies?
>
> Or any Ideas what else I have to set?

Can you look (from the PHP side) at ALL the headers recevied.  That
should be the first step in debugging.



From jpthing at online.no  Tue Oct 27 02:17:01 2009
From: jpthing at online.no (John Thingstad)
Date: Tue, 27 Oct 2009 03:17:01 +0100
Subject: [hunchentoot-devel] updated version
Message-ID: <1256609821.12526.5.camel@Pandora>

Where is the the current SVN version of Hunchentoot that you are working
on located? It seems the huncentoot version at www.weitz.de hasn't been
updated in ages.





From hans.huebner at gmail.com  Tue Oct 27 05:52:14 2009
From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Tue, 27 Oct 2009 06:52:14 +0100
Subject: [hunchentoot-devel] updated version
In-Reply-To: <1256609821.12526.5.camel@Pandora>
References: <1256609821.12526.5.camel@Pandora>
Message-ID: <fd2982320910262252k14c7951ap67dd26aac7abdbb2@mail.gmail.com>

On Tue, Oct 27, 2009 at 03:17, John Thingstad <jpthing at online.no> wrote:
> Where is the the current SVN version of Hunchentoot that you are working
> on located? It seems the huncentoot version at www.weitz.de hasn't been
> updated in ages.

If you want to track the latest development version, check out
http://bknr.net/svn/ediware/ using svn.

-Hans



From edi at agharta.de  Tue Oct 27 06:53:27 2009
From: edi at agharta.de (Edi Weitz)
Date: Tue, 27 Oct 2009 07:53:27 +0100
Subject: [hunchentoot-devel] updated version
In-Reply-To: <1256609821.12526.5.camel@Pandora>
References: <1256609821.12526.5.camel@Pandora>
Message-ID: <b56421a00910262353o79d6f08ya08d2ccbeaea241d@mail.gmail.com>

On Tue, Oct 27, 2009 at 3:17 AM, John Thingstad <jpthing at online.no> wrote:
> Where is the the current SVN version of Hunchentoot that you are working
> on located? It seems the huncentoot version at www.weitz.de hasn't been
> updated in ages.

The last update was in February.  How often do I need to update it in
order to make it acceptable to you?



From jpthing at online.no  Tue Oct 27 11:57:51 2009
From: jpthing at online.no (John Thingstad)
Date: Tue, 27 Oct 2009 12:57:51 +0100
Subject: [hunchentoot-devel] updated version
In-Reply-To: <b56421a00910262353o79d6f08ya08d2ccbeaea241d@mail.gmail.com>
References: <1256609821.12526.5.camel@Pandora>
	<b56421a00910262353o79d6f08ya08d2ccbeaea241d@mail.gmail.com>
Message-ID: <1256644671.12526.10.camel@Pandora>

ti., 27.10.2009 kl. 07.53 +0100, skrev Edi Weitz:
> On Tue, Oct 27, 2009 at 3:17 AM, John Thingstad <jpthing at online.no> wrote:
> > Where is the the current SVN version of Hunchentoot that you are working
> > on located? It seems the huncentoot version at www.weitz.de hasn't been
> > updated in ages.
> 
> The last update was in February.  How often do I need to update it in
> order to make it acceptable to you?
> 

Depends. The 1.0 version contains obvious errors like stop doesn't work.
As so it is more of a beta version and I desire to update more often. I
know people are aware of some of the problems and release patches, but I
didn't know where they went.




From edi at agharta.de  Tue Oct 27 13:32:57 2009
From: edi at agharta.de (Edi Weitz)
Date: Tue, 27 Oct 2009 14:32:57 +0100
Subject: [hunchentoot-devel] updated version
In-Reply-To: <1256644671.12526.10.camel@Pandora>
References: <1256609821.12526.5.camel@Pandora>
	<b56421a00910262353o79d6f08ya08d2ccbeaea241d@mail.gmail.com>
	<1256644671.12526.10.camel@Pandora>
Message-ID: <b56421a00910270632q2ccf4e35ye8040e1f07682bee@mail.gmail.com>

On Tue, Oct 27, 2009 at 12:57 PM, John Thingstad <jpthing at online.no> wrote:

> Depends. The 1.0 version contains obvious errors like stop doesn't work.

STOP doesn't work?  The acceptor will still accept requests after you
called STOP?  Or what is the problem?

And which other errors are you talking about?



From billstclair at gmail.com  Tue Oct 27 13:52:08 2009
From: billstclair at gmail.com (Bill St. Clair)
Date: Tue, 27 Oct 2009 09:52:08 -0400
Subject: [hunchentoot-devel] updated version
In-Reply-To: <b56421a00910270632q2ccf4e35ye8040e1f07682bee@mail.gmail.com>
References: <1256609821.12526.5.camel@Pandora>
	<b56421a00910262353o79d6f08ya08d2ccbeaea241d@mail.gmail.com>
	<1256644671.12526.10.camel@Pandora>
	<b56421a00910270632q2ccf4e35ye8040e1f07682bee@mail.gmail.com>
Message-ID: <8fbe874a0910270652k4d22fb90wa6884253270be79c@mail.gmail.com>

For me, STOP returns, but the listener process doesn't exit. To make
it do so in CCL, I've used the following. Haven't tried this in other
lisps. The full drakma:http-request is probably not necessary, just
something sent over the port to wake up the listener process. But I
haven't tried that either.

-Bill

              (let ((started nil))
                (process-run-function
                 (format nil "Stop port ~d" port)
                 (lambda ()
                   (setq started t)
                   (hunchentoot:stop acceptor)))
                (process-wait "Server stopper" (lambda () started)))
              ;; Need to make a request in order to get the server to shut down
              (ignore-errors
                (let ((ssl-p (hunchentoot:ssl-p acceptor)))
                  (dotimes (i 3)
                    (drakma:http-request
                     (format nil "~a://localhost:~d/"
                             (if ssl-p "https" "http") port)
                     :redirect nil)))))))))

On Tue, Oct 27, 2009 at 9:32 AM, Edi Weitz <edi at agharta.de> wrote:
> On Tue, Oct 27, 2009 at 12:57 PM, John Thingstad <jpthing at online.no> wrote:
>
>> Depends. The 1.0 version contains obvious errors like stop doesn't work.
>
> STOP doesn't work? ?The acceptor will still accept requests after you
> called STOP? ?Or what is the problem?
>
> And which other errors are you talking about?
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>



From helmut at cybernetic-systems.de  Tue Oct 27 15:58:03 2009
From: helmut at cybernetic-systems.de (Dr. Helmut G. Enders)
Date: Tue, 27 Oct 2009 16:58:03 +0100
Subject: [hunchentoot-devel] updated version
In-Reply-To: <b56421a00910270632q2ccf4e35ye8040e1f07682bee@mail.gmail.com>
References: <1256609821.12526.5.camel@Pandora>	<b56421a00910262353o79d6f08ya08d2ccbeaea241d@mail.gmail.com>	<1256644671.12526.10.camel@Pandora>
	<b56421a00910270632q2ccf4e35ye8040e1f07682bee@mail.gmail.com>
Message-ID: <4AE7188B.3060002@cybernetic-systems.de>

Edi Weitz wrote:
> On Tue, Oct 27, 2009 at 12:57 PM, John Thingstad <jpthing at online.no> wrote:
>
>   
>> Depends. The 1.0 version contains obvious errors like stop doesn't work.
>>     
>
> STOP doesn't work?  The acceptor will still accept requests after you
> called STOP?  Or what is the problem?
>
> And which other errors are you talking about?
>   
I have the same problem:
   debian 2.6.30-2-amd64
   sbcl 1.0.31.32
   hunchentoot 1.0
   emacs23 -> slime ->sbcl

after
(setf *http-server* (hunchentoot:start (make-instance 
'hunchentoot:acceptor))
(hunchentoot:stop *http-server*)

There is no response (break, ^G ^C ^D etc.) in the REPL.
I have to kill the sbcl process.

Helmut






From dochang at gmail.com  Tue Oct 27 16:48:35 2009
From: dochang at gmail.com (Desmond O. Chang)
Date: Wed, 28 Oct 2009 00:48:35 +0800
Subject: [hunchentoot-devel] [PATCH] maybe-read-post-parameters should pass
	`request' to raw-post-data
Message-ID: <1256662115-3255-1-git-send-email-dochang@gmail.com>

---
 source/hunchentoot/request.lisp |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/source/hunchentoot/request.lisp b/source/hunchentoot/request.lisp
index 776113a..ed194c6 100644
--- a/source/hunchentoot/request.lisp
+++ b/source/hunchentoot/request.lisp
@@ -305,7 +305,7 @@ unknown character set ~A in request content type."
                   (cond ((and (string-equal type "application")
                               (string-equal subtype "x-www-form-urlencoded"))
                          (form-url-encoded-list-to-alist
-                          (split "&" (raw-post-data :external-format +latin-1+))
+                          (split "&" (raw-post-data :request request :external-format +latin-1+))
                           external-format))
                         ((and (string-equal type "multipart")
                               (string-equal subtype "form-data"))
-- 
1.6.5




From christoph.senjak at googlemail.com  Wed Oct 28 00:42:54 2009
From: christoph.senjak at googlemail.com (Christoph Senjak)
Date: Wed, 28 Oct 2009 01:42:54 +0100
Subject: [hunchentoot-devel] Preventing Hunchentoot from parsing the
	POST-Data
Message-ID: <33ed8ce70910271742i54c7040x321f5bb1686dd28c@mail.gmail.com>

Hello.

I am still trying to get PHP (and cgi in general) work behind
Hunchentoot. The implementation of Cyrus Harmon does (besides not
providing some necessary env-vars) not pass the postdata to the
cgi-script. Using raw-post-data seems not to work (even when saying
:want-stream nil) and always return nil as far as I saw.

Can I somehow tell hunchentoot not to read and parse the post-data,
but leaving raw-post-data as a binary stream which I can pass to the
cgi-handler?

Regards, Christoph



From hans.huebner at gmail.com  Wed Oct 28 06:28:47 2009
From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Wed, 28 Oct 2009 07:28:47 +0100
Subject: [hunchentoot-devel] Preventing Hunchentoot from parsing the
	POST-Data
In-Reply-To: <33ed8ce70910271742i54c7040x321f5bb1686dd28c@mail.gmail.com>
References: <33ed8ce70910271742i54c7040x321f5bb1686dd28c@mail.gmail.com>
Message-ID: <fd2982320910272328h448e9656i2e120563e30bb5c1@mail.gmail.com>

On Wed, Oct 28, 2009 at 01:42, Christoph Senjak
<christoph.senjak at googlemail.com> wrote:
> Can I somehow tell hunchentoot not to read and parse the post-data,
> but leaving raw-post-data as a binary stream which I can pass to the
> cgi-handler?

Hunchentoot is designed as terminating HTTP server, i.e. it does not
expect to forward requests.  For this, it is required that any request
body is eventually read from the stream during handler processing.  It
should be possible to make request forwarding work, but that will
require tracing the internals of Hunchentoot and finding out where and
why the post body is actually read, then come up with a configurable
mechanism to supress request body processing for certain requests.

Before sending patches, please make sure that you've read
http://weitz.de/patches.html - You may also want to post your
implementation plan here before submitting a patch.

-Hans



From hans.huebner at gmail.com  Wed Oct 28 06:20:00 2009
From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Wed, 28 Oct 2009 07:20:00 +0100
Subject: [hunchentoot-devel] [PATCH] maybe-read-post-parameters should
	pass `request' to raw-post-data
In-Reply-To: <1256662115-3255-1-git-send-email-dochang@gmail.com>
References: <1256662115-3255-1-git-send-email-dochang@gmail.com>
Message-ID: <fd2982320910272320g2de67f0as3de96f51fea4086@mail.gmail.com>

Committed, thanks.

On Tue, Oct 27, 2009 at 17:48, Desmond O. Chang <dochang at gmail.com> wrote:
> ---
> ?source/hunchentoot/request.lisp | ? ?2 +-
> ?1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/source/hunchentoot/request.lisp b/source/hunchentoot/request.lisp
> index 776113a..ed194c6 100644
> --- a/source/hunchentoot/request.lisp
> +++ b/source/hunchentoot/request.lisp
> @@ -305,7 +305,7 @@ unknown character set ~A in request content type."
> ? ? ? ? ? ? ? ? ? (cond ((and (string-equal type "application")
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? (string-equal subtype "x-www-form-urlencoded"))
> ? ? ? ? ? ? ? ? ? ? ? ? ?(form-url-encoded-list-to-alist
> - ? ? ? ? ? ? ? ? ? ? ? ? ?(split "&" (raw-post-data :external-format +latin-1+))
> + ? ? ? ? ? ? ? ? ? ? ? ? ?(split "&" (raw-post-data :request request :external-format +latin-1+))
> ? ? ? ? ? ? ? ? ? ? ? ? ? external-format))
> ? ? ? ? ? ? ? ? ? ? ? ? ((and (string-equal type "multipart")
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? (string-equal subtype "form-data"))
> --
> 1.6.5
>
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>



From christoph.senjak at googlemail.com  Wed Oct 28 11:13:32 2009
From: christoph.senjak at googlemail.com (Christoph Senjak)
Date: Wed, 28 Oct 2009 12:13:32 +0100
Subject: [hunchentoot-devel] Preventing Hunchentoot from parsing the
	POST-Data
In-Reply-To: <fd2982320910272328h448e9656i2e120563e30bb5c1@mail.gmail.com>
References: <33ed8ce70910271742i54c7040x321f5bb1686dd28c@mail.gmail.com>
	<fd2982320910272328h448e9656i2e120563e30bb5c1@mail.gmail.com>
Message-ID: <33ed8ce70910280413k7403d339i49ca377a1e5ec89c@mail.gmail.com>

Hello.

2009/10/28 Hans H?bner <hans.huebner at gmail.com>:
> On Wed, Oct 28, 2009 at 01:42, Christoph Senjak
> <christoph.senjak at googlemail.com> wrote:
>> Can I somehow tell hunchentoot not to read and parse the post-data,
>> but leaving raw-post-data as a binary stream which I can pass to the
>> cgi-handler?
>
> Hunchentoot is designed as terminating HTTP server, i.e. it does not
> expect to forward requests. ?For this, it is required that any request
> body is eventually read from the stream during handler processing.
Hm. Ok, then I wonder why raw-post-data exists anyway.

> It
> should be possible to make request forwarding work, but that will
> require tracing the internals of Hunchentoot and finding out where and
> why the post body is actually read, then come up with a configurable
> mechanism to supress request body processing for certain requests.
To me it seems like this is done inside maybe-read-post-parameters,
which is called when using the post-parameters-slot-accessor. I dont
see any other part where this is called. But of course, I am not sure.
Modifying this function such that it doesnt read anything when - say -
some flag like (dont-read-post-data *request*) is set to T, should be
easy, but the question is if it is enough then to set it to T in the
handler-function itself, or if this has to be done in the dispatcher
already?

> Before sending patches, please make sure that you've read
> http://weitz.de/patches.html - You may also want to post your
> implementation plan here before submitting a patch.
Ok.

Regards, Christoph



From xach at xach.com  Wed Oct 28 11:25:18 2009
From: xach at xach.com (Zach Beane)
Date: Wed, 28 Oct 2009 07:25:18 -0400
Subject: [hunchentoot-devel] Preventing Hunchentoot from parsing the
	POST-Data
In-Reply-To: <33ed8ce70910280413k7403d339i49ca377a1e5ec89c@mail.gmail.com>
References: <33ed8ce70910271742i54c7040x321f5bb1686dd28c@mail.gmail.com>
	<fd2982320910272328h448e9656i2e120563e30bb5c1@mail.gmail.com>
	<33ed8ce70910280413k7403d339i49ca377a1e5ec89c@mail.gmail.com>
Message-ID: <20091028112518.GI21609@xach.com>

On Wed, Oct 28, 2009 at 12:13:32PM +0100, Christoph Senjak wrote:
> Hello.
> 
> 2009/10/28 Hans H?bner <hans.huebner at gmail.com>:
> > On Wed, Oct 28, 2009 at 01:42, Christoph Senjak
> > <christoph.senjak at googlemail.com> wrote:
> >> Can I somehow tell hunchentoot not to read and parse the post-data,
> >> but leaving raw-post-data as a binary stream which I can pass to the
> >> cgi-handler?
> >
> > Hunchentoot is designed as terminating HTTP server, i.e. it does not
> > expect to forward requests. ?For this, it is required that any request
> > body is eventually read from the stream during handler processing.
> Hm. Ok, then I wonder why raw-post-data exists anyway.

I wrote the patch for it some time ago to work with PayPal's "IPN"
postback system of payment notification. There is a confirmation step
that requires you post their post data back to them exactly as you
received it.

The PDF at https://www.paypal.com/ipn has more information.

Zach



From edi at agharta.de  Wed Oct 28 12:10:44 2009
From: edi at agharta.de (Edi Weitz)
Date: Wed, 28 Oct 2009 13:10:44 +0100
Subject: [hunchentoot-devel] Preventing Hunchentoot from parsing the
	POST-Data
In-Reply-To: <33ed8ce70910280413k7403d339i49ca377a1e5ec89c@mail.gmail.com>
References: <33ed8ce70910271742i54c7040x321f5bb1686dd28c@mail.gmail.com>
	<fd2982320910272328h448e9656i2e120563e30bb5c1@mail.gmail.com>
	<33ed8ce70910280413k7403d339i49ca377a1e5ec89c@mail.gmail.com>
Message-ID: <b56421a00910280510s238bc87ewc96ec44d6a50d554@mail.gmail.com>

On Wed, Oct 28, 2009 at 12:13 PM, Christoph Senjak
<christoph.senjak at googlemail.com> wrote:

> Hm. Ok, then I wonder why raw-post-data exists anyway.

So that you can get at the raw, unparsed data the client sent.  There
are more content types than multipart/form-data and
application/x-www-form-urlencoded.  See also what Zach wrote.

> To me it seems like this is done inside maybe-read-post-parameters,
> which is called when using the post-parameters-slot-accessor. I dont
> see any other part where this is called. But of course, I am not sure.
> Modifying this function such that it doesnt read anything when - say -
> some flag like (dont-read-post-data *request*) is set to T, should be
> easy

But why would you want to do that?  If you are forwarding a request,
you shouldn't try to access the post parameters at the same time,
should you?

Unless my memory fails me, the request body will only be read (unless
your application code does it, of course), at the beginning of
START-OUTPUT to clear the stream.  If you have code in place that took
care of the request body already (by reading from the stream), that
should be a no-op.

Right now, I don't really see why you shouldn't be able to do what you
want with the current code - although I haven't tried it myself.



From sebyte at smolny.plus.com  Wed Oct 28 16:13:52 2009
From: sebyte at smolny.plus.com (Sebastian Tennant)
Date: Wed, 28 Oct 2009 16:13:52 +0000
Subject: [hunchentoot-devel] updated version
References: <1256609821.12526.5.camel@Pandora>
	<b56421a00910262353o79d6f08ya08d2ccbeaea241d@mail.gmail.com>
	<1256644671.12526.10.camel@Pandora>
	<b56421a00910270632q2ccf4e35ye8040e1f07682bee@mail.gmail.com>
	<4AE7188B.3060002@cybernetic-systems.de>
Message-ID: <8wev339b.fsf@vps203.linuxvps.org>

Quoth "Dr. Helmut G. Enders" <helmut at cybernetic-systems.de>:
> There is no response (break, ^G ^C ^D etc.) in the REPL.
> I have to kill the sbcl process.

Plus one.

Seb
-- 
Emacs' AlsaPlayer - Music Without Jolts
Lightweight, full-featured and mindful of your idyllic happiness.
http://home.gna.org/eap




From helmut at cybernetic-systems.de  Thu Oct 29 08:40:27 2009
From: helmut at cybernetic-systems.de (helmut at cybernetic-systems.de)
Date: Thu, 29 Oct 2009 09:40:27 +0100
Subject: [hunchentoot-devel] updated version
In-Reply-To: <4AE7188B.3060002@cybernetic-systems.de>
References: <1256609821.12526.5.camel@Pandora>	<b56421a00910262353o79d6f08ya08d2ccbeaea241d@mail.gmail.com>	<1256644671.12526.10.camel@Pandora>
	<b56421a00910270632q2ccf4e35ye8040e1f07682bee@mail.gmail.com>
	<4AE7188B.3060002@cybernetic-systems.de>
Message-ID: <4AE954FB.5080002@cybernetic-systems.de>

Dr. Helmut G. Enders wrote:
> Edi Weitz wrote:
>> On Tue, Oct 27, 2009 at 12:57 PM, John Thingstad <jpthing at online.no> 
>> wrote:
>>
>>  
>>> Depends. The 1.0 version contains obvious errors like stop doesn't 
>>> work.
>>>     
>>
>> STOP doesn't work?  The acceptor will still accept requests after you
>> called STOP?  Or what is the problem?
>>
>> And which other errors are you talking about?
>>   
> I have the same problem:
>   debian 2.6.30-2-amd64
>   sbcl 1.0.31.32
>   hunchentoot 1.0
>   emacs23 -> slime ->sbcl
>
> after
> (setf *http-server* (hunchentoot:start (make-instance 
> 'hunchentoot:acceptor))
> (hunchentoot:stop *http-server*)
>
> There is no response (break, ^G ^C ^D etc.) in the REPL.
> I have to kill the sbcl process.
Vanished after    svn co svn://bknr.net/svn/ediware
and works like a charm, thanks,
Helmut