From jc at itsec.co.kr  Tue May  1 03:13:04 2007
From: jc at itsec.co.kr (Jong-won Choi)
Date: Tue, 01 May 2007 12:13:04 +0900
Subject: [hunchentoot-devel] User defined http return codes
Message-ID: <4636B040.2010601@itsec.co.kr>

Currently if a user want to define a custom http return code, s/he has 
to change reason-phrase function manually.

The attached patch file is my suggestion on this problem.

Cheers

Jong-won

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: htoot-patch
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20070501/eec6c00f/attachment.ksh>

From asf at boinkor.net  Tue May  1 13:43:12 2007
From: asf at boinkor.net (Andreas Fuchs)
Date: Tue, 01 May 2007 15:43:12 +0200
Subject: [hunchentoot-devel] CL-WEBDAV and OS X (locks, class 2 compliance)
Message-ID: <463743F0.9070303@boinkor.net>

Hi there,

I just tried out CL-WEBDAV, and I would like to use it in a pet project
of mine (making a simple-to-deploy WebDAV service that Mac OS X clients
can use without much hassle). The Finder mounts CL-WEBDAV volumes just
fine, but only in read-only mode. So, I guess I'll need locking support
to get read-write mounts of WebDAV volumes in the Finder.

The cl-webdav documentation says that I should bribe Edi to get this
feature. So, Edi, how large should the bribe be for working locks? (-:

Cheers,
-- 
Andreas Fuchs, (http://|im:asf@|mailto:asf@)boinkor.net, antifuchs



From edi at agharta.de  Tue May  1 13:49:45 2007
From: edi at agharta.de (Edi Weitz)
Date: Tue, 01 May 2007 15:49:45 +0200
Subject: [hunchentoot-devel] Re: Boolean Form Fields
In-Reply-To: <87ejm45pdw.fsf@ttnet.net.tr> (Volkan YAZICI's message of "Sat,
	28 Apr 2007 21:23:55 +0300")
References: <87bqh97c76.fsf@ttnet.net.tr> <ups5pmqmj.fsf@agharta.de>
	<87ejm45pdw.fsf@ttnet.net.tr>
Message-ID: <uejm0k612.fsf@agharta.de>

On Sat, 28 Apr 2007 21:23:55 +0300, Volkan YAZICI <yazicivo at ttnet.net.tr> wrote:

> Try this handler with "/auth?result=", "/auth?result=nil" URIs. In
> each case, RESULT will return T. So how can I tell /auth that I
> tried to authenticate the client but it's failed? (You may say that,
> just don't pass the `result' argument to URI. But that's not same as
> passing a boolean type of argument with NIL/FALSE value.)

Sorry for the delay.  My take is that the BOOLEAN parameter type of
DEFINE-EASY-HANDLERS was made to work with checkboxes and such as
submitted by browsers.  I agree that it can't work with arbitrary ways
to pass GET parameters, but that's similar to the problem in databases
where in addition to "true" and "false" you also have a "NULL" value.

I'd prefer not to change the existing code, but I'm prepared to be
overruled if several users think it should be changed and come up with
a reasonable alternative.


From edi at agharta.de  Tue May  1 14:08:07 2007
From: edi at agharta.de (Edi Weitz)
Date: Tue, 01 May 2007 16:08:07 +0200
Subject: [hunchentoot-devel] New release 0.9.2 (Was: User defined http
	return codes)
In-Reply-To: <4636B040.2010601@itsec.co.kr> (Jong-won Choi's message of
	"Tue, 01 May 2007 12:13:04 +0900")
References: <4636B040.2010601@itsec.co.kr>
Message-ID: <uabwok56g.fsf@agharta.de>

On Tue, 01 May 2007 12:13:04 +0900, Jong-won Choi <jc at itsec.co.kr> wrote:

> Currently if a user want to define a custom http return code, s/he
> has to change reason-phrase function manually.
>
> The attached patch file is my suggestion on this problem.

Thanks, I've made a new release with a modified version of your patch.

> +  (defconstant +http-code-reason-table+ (make-hash-table :test #'eq))

That's not portable, you should use EQL.  Also, please don't create
new functions or variables without doc strings.  See

  http://weitz.de/patches.html

Thanks,
Edi.


From info at jensteich.de  Tue May  1 14:35:03 2007
From: info at jensteich.de (Jens Teich)
Date: Tue, 1 May 2007 16:35:03 +0200
Subject: [hunchentoot-devel] Connection to Postgres via Postmodern with
	Unicode
Message-ID: <010301c78bfd$ec53cc50$6f02a8c0@JensSony>

> Where do you set the content type header?
 
 Tried
 
 (setf *default-content-type* "text/html;charset=UTF-8")
 
 but wasn't successful.
 
 Any hint would be very nice ...
 
 Something else is confusing me. When using clsql with :database-type
odbc I can see the unicode characters correctly in the header
without having 
 to care about content type header.
 
 -jens


From edi at agharta.de  Tue May  1 14:43:44 2007
From: edi at agharta.de (Edi Weitz)
Date: Tue, 01 May 2007 16:43:44 +0200
Subject: [hunchentoot-devel] Connection to Postgres via Postmodern with
	Unicode
In-Reply-To: <010301c78bfd$ec53cc50$6f02a8c0@JensSony> (Jens Teich's message
	of "Tue, 1 May 2007 16:35:03 +0200")
References: <010301c78bfd$ec53cc50$6f02a8c0@JensSony>
Message-ID: <uslagioyn.fsf@agharta.de>

On Tue, 1 May 2007 16:35:03 +0200, "Jens Teich" <info at jensteich.de> wrote:

>  Tried
>  
>  (setf *default-content-type* "text/html;charset=UTF-8")
>  
>  but wasn't successful.

Did you set the external format of the output stream correctly?

>  Any hint would be very nice ...

Can you send a backtrace?
  
> Something else is confusing me. When using clsql with :database-type
> odbc I can see the unicode characters correctly in the header

Headers should only contain ASCII characters anyway.


From edi at agharta.de  Tue May  1 14:45:07 2007
From: edi at agharta.de (Edi Weitz)
Date: Tue, 01 May 2007 16:45:07 +0200
Subject: [hunchentoot-devel] Connection to Postgres via Postmodern with
	Unicode
In-Reply-To: <uslagioyn.fsf@agharta.de> (Edi Weitz's message of "Tue, 01 May
	2007 16:43:44 +0200")
References: <010301c78bfd$ec53cc50$6f02a8c0@JensSony>
	<uslagioyn.fsf@agharta.de>
Message-ID: <uodl4iowc.fsf@agharta.de>

On Tue, 01 May 2007 16:43:44 +0200, Edi Weitz <edi at agharta.de> wrote:

> Did you set the external format of the output stream correctly?

Hunchentoot comes with example code which shows several ways how this
can be done:

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


From emailmac at gmail.com  Thu May  3 08:14:54 2007
From: emailmac at gmail.com (Mac Chan)
Date: Thu, 3 May 2007 01:14:54 -0700
Subject: [hunchentoot-devel] resurrect tbnl's debug-value macro?
Message-ID: <4877ae640705030114m40ede33ah864f5d2018755898@mail.gmail.com>

I just noticed today that one of the tbnl's best features is missing
in hunchentoot.

Previously (in tbnl) if you set *debug-mode* to T, the top level
dynamic vars *request*, *reply*, etc will be bound to the last
request, reply objects.

This is very handy and in line with Lisp's interactive development model.

I usually setup an empty handler and point the browser to that URL.

Now I can work with the *request* / *reply* objects in the REPL, and
write html generation and GET/POST handling code interactively.

For instance, I can type these in the REPL

> (setf hunchentoot::*session* (hunchentoot::session-verify *request*))

> (session-value :selected-product)
"T-Shirt XXL"

> (* (product-price *) (session-value :quantity))
15

and so on.

Once I'm satisfied with the result, I put all the code into the handler.

(defun product-total-page (&optional (request *request*))
  (let ((p (session-value :selected-product))
        (q (session-value :quantity)))
   (with-html
     (:html
      (:body
       (:table
        (:tr (:td "Product") (:td (str p)))
        (:tr (:td "Quantity") (:td (str q)))
        (:tr (:td "Total") (:td (str (* q (product-price p)))))))))))

This is also very handy for debugging (inspect *request*'s slots -
cookies, header and whatnot).

Thoughts?

-- Mac


From edi at agharta.de  Thu May  3 08:22:52 2007
From: edi at agharta.de (Edi Weitz)
Date: Thu, 03 May 2007 10:22:52 +0200
Subject: [hunchentoot-devel] resurrect tbnl's debug-value macro?
In-Reply-To: <4877ae640705030114m40ede33ah864f5d2018755898@mail.gmail.com> (Mac
	Chan's message of "Thu, 3 May 2007 01:14:54 -0700")
References: <4877ae640705030114m40ede33ah864f5d2018755898@mail.gmail.com>
Message-ID: <u4pmuiaeb.fsf@agharta.de>

On Thu, 3 May 2007 01:14:54 -0700, "Mac Chan" <emailmac at gmail.com> wrote:

> I just noticed today that one of the tbnl's best features is missing
> in hunchentoot.
>
> Previously (in tbnl) if you set *debug-mode* to T, the top level
> dynamic vars *request*, *reply*, etc will be bound to the last
> request, reply objects.
>
> This is very handy and in line with Lisp's interactive development
> model.
>
> I usually setup an empty handler and point the browser to that URL.
>
> Now I can work with the *request* / *reply* objects in the REPL, and
> write html generation and GET/POST handling code interactively.
>
> For instance, I can type these in the REPL
>
>> (setf hunchentoot::*session* (hunchentoot::session-verify *request*))
>
>> (session-value :selected-product)
> "T-Shirt XXL"
>
>> (* (product-price *) (session-value :quantity))
> 15
>
> and so on.
>
> Once I'm satisfied with the result, I put all the code into the handler.
>
> (defun product-total-page (&optional (request *request*))
>   (let ((p (session-value :selected-product))
>         (q (session-value :quantity)))
>    (with-html
>      (:html
>       (:body
>        (:table
>         (:tr (:td "Product") (:td (str p)))
>         (:tr (:td "Quantity") (:td (str q)))
>         (:tr (:td "Total") (:td (str (* q (product-price p)))))))))))
>
> This is also very handy for debugging (inspect *request*'s slots -
> cookies, header and whatnot).
>
> Thoughts?

I removed these variables when porting TBNL because it turned out that
I never used them and I had never heard from anyone else who used
them.  It seems I misjudged... :)

However, can't you have the same result if you add (BREAK) to your
empty handler and set *CATCH-ERRORS-P* to NIL?  I think that
*CATCH-ERRORS-P* is a superior replacement to *DEBUG-MODE* as you
don't have to rely on your clients to not send more than one request.

Cheers,
Edi.


From nowhere.man at levallois.eu.org  Thu May  3 11:17:48 2007
From: nowhere.man at levallois.eu.org (Pierre THIERRY)
Date: Thu, 3 May 2007 13:17:48 +0200
Subject: [hunchentoot-devel] resurrect tbnl's debug-value macro?
In-Reply-To: <4877ae640705030114m40ede33ah864f5d2018755898@mail.gmail.com>
References: <4877ae640705030114m40ede33ah864f5d2018755898@mail.gmail.com>
Message-ID: <20070503111748.GX16339@bateleur.arcanes.fr.eu.org>

Scribit Mac Chan dies 03/05/2007 hora 01:14:
> Previously (in tbnl) if you set *debug-mode* to T, the top level
> dynamic vars *request*, *reply*, etc will be bound to the last
> request, reply objects.
>
> [...]
>
> Thoughts?

This is something I usually do myself, and I save this kind of objects
in debug-specific variables. The *debug-mode* behaviour won't scale,
because you have to be sure there will only be a single HTTP request
sent to the server, or the various variables will be overwritten.

Just do it yourself, with a handler "leaking" the objects you want to
inspect:

(defvar *leak*)

(defun leaking-handler ()
  (setf *leak* (list *request* *reply*))
  "<html><head><title>Leaked</title></head><body>Leaked.</body></html>")

Scalably,
Pierre
-- 
nowhere.man at levallois.eu.org
OpenPGP 0xD9D50D8A
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20070503/7464c88d/attachment.sig>

From lispercat at gmail.com  Thu May  3 12:25:21 2007
From: lispercat at gmail.com (Andrei Stebakov)
Date: Thu, 3 May 2007 08:25:21 -0400
Subject: [hunchentoot-devel] resurrect tbnl's debug-value macro?
In-Reply-To: <20070503111748.GX16339@bateleur.arcanes.fr.eu.org>
References: <4877ae640705030114m40ede33ah864f5d2018755898@mail.gmail.com>
	<20070503111748.GX16339@bateleur.arcanes.fr.eu.org>
Message-ID: <affe56e00705030525t5d37e90chfd0fbf806bacbad8@mail.gmail.com>

I would really vote for the feature. I didn't know it existed before. Also
the (break) doesn't always work well with slime environment (at least in my
case) and it doesn't go well with the lisp flowy programming model (so you
can build all the functionality from REPL using functions as building
blocks).

Andrew

On 5/3/07, Pierre THIERRY <nowhere.man at levallois.eu.org> wrote:
>
> Scribit Mac Chan dies 03/05/2007 hora 01:14:
> > Previously (in tbnl) if you set *debug-mode* to T, the top level
> > dynamic vars *request*, *reply*, etc will be bound to the last
> > request, reply objects.
> >
> > [...]
> >
> > Thoughts?
>
> This is something I usually do myself, and I save this kind of objects
> in debug-specific variables. The *debug-mode* behaviour won't scale,
> because you have to be sure there will only be a single HTTP request
> sent to the server, or the various variables will be overwritten.
>
> Just do it yourself, with a handler "leaking" the objects you want to
> inspect:
>
> (defvar *leak*)
>
> (defun leaking-handler ()
>   (setf *leak* (list *request* *reply*))
>   "<html><head><title>Leaked</title></head><body>Leaked.</body></html>")
>
> Scalably,
> Pierre
> --
> nowhere.man at levallois.eu.org
> OpenPGP 0xD9D50D8A
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFGOcTcxe13INnVDYoRAg4VAKDBoE3rkhpJhAnwRLjm14NlIonAhwCfWDrf
> y4qWWj0+lFP4nyCz7OkBGDQ=
> =cHRq
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> 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/20070503/37947913/attachment.html>

From nowhere.man at levallois.eu.org  Thu May  3 13:04:23 2007
From: nowhere.man at levallois.eu.org (Pierre THIERRY)
Date: Thu, 3 May 2007 15:04:23 +0200
Subject: [hunchentoot-devel] resurrect tbnl's debug-value macro?
In-Reply-To: <affe56e00705030525t5d37e90chfd0fbf806bacbad8@mail.gmail.com>
References: <4877ae640705030114m40ede33ah864f5d2018755898@mail.gmail.com>
	<20070503111748.GX16339@bateleur.arcanes.fr.eu.org>
	<affe56e00705030525t5d37e90chfd0fbf806bacbad8@mail.gmail.com>
Message-ID: <20070503130423.GY16339@bateleur.arcanes.fr.eu.org>

Scribit Andrei Stebakov dies 03/05/2007 hora 08:25:
> I would really vote for the feature.

Bear in mind that it goes in the critical path WRT performance. Each if
form in the code serving data and each cache msis coming with it makes
Hunchentoot a tiny bit less performant.

As it is a debugging tool that can only be used in a very limited set of
cases, and that general purpose and scalable solutions can be done in a
few lines outside Hunchentoot's core, I don't think it's worth it.

Quickly,
Pierre
-- 
nowhere.man at levallois.eu.org
OpenPGP 0xD9D50D8A
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20070503/f53f96b4/attachment.sig>

From rsynnott at gmail.com  Thu May  3 13:33:40 2007
From: rsynnott at gmail.com (Robert Synnott)
Date: Thu, 3 May 2007 14:33:40 +0100
Subject: [hunchentoot-devel] resurrect tbnl's debug-value macro?
In-Reply-To: <20070503111748.GX16339@bateleur.arcanes.fr.eu.org>
References: <4877ae640705030114m40ede33ah864f5d2018755898@mail.gmail.com>
	<20070503111748.GX16339@bateleur.arcanes.fr.eu.org>
Message-ID: <24f203480705030633r50bbec33id60e599325369406@mail.gmail.com>

On 5/3/07, Pierre THIERRY <nowhere.man at levallois.eu.org> wrote:
>...
> Just do it yourself, with a handler "leaking" the objects you want to
> inspect:
>
> (defvar *leak*)
>
> (defun leaking-handler ()
>   (setf *leak* (list *request* *reply*))
>   "<html><head><title>Leaked</title></head><body>Leaked.</body></html>")
>
> Scalably,
> Pierre

I do this as well, but the debug-mode thing actually sounds very handy
(of course, it's not useful for debugging running applications).
Rob.


From danielgackle at gmail.com  Thu May  3 17:03:04 2007
From: danielgackle at gmail.com (Daniel Gackle)
Date: Thu, 3 May 2007 11:03:04 -0600
Subject: [hunchentoot-devel] resurrect tbnl's debug-value macro?
In-Reply-To: <24f203480705030633r50bbec33id60e599325369406@mail.gmail.com>
References: <4877ae640705030114m40ede33ah864f5d2018755898@mail.gmail.com>
	<20070503111748.GX16339@bateleur.arcanes.fr.eu.org>
	<24f203480705030633r50bbec33id60e599325369406@mail.gmail.com>
Message-ID: <57952f8b0705031003k6a7738dajf2470a353d4138b8@mail.gmail.com>

I found *debug-mode* useful as well.

Dan


On 5/3/07, Robert Synnott <rsynnott at gmail.com> wrote:
>
> On 5/3/07, Pierre THIERRY <nowhere.man at levallois.eu.org> wrote:
> >...
> > Just do it yourself, with a handler "leaking" the objects you want to
> > inspect:
> >
> > (defvar *leak*)
> >
> > (defun leaking-handler ()
> >   (setf *leak* (list *request* *reply*))
> >   "<html><head><title>Leaked</title></head><body>Leaked.</body></html>")
> >
> > Scalably,
> > Pierre
>
> I do this as well, but the debug-mode thing actually sounds very handy
> (of course, it's not useful for debugging running applications).
> Rob.
> _______________________________________________
> 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/20070503/9ca54ae9/attachment.html>

From emailmac at gmail.com  Thu May  3 17:39:06 2007
From: emailmac at gmail.com (Mac Chan)
Date: Thu, 3 May 2007 10:39:06 -0700
Subject: [hunchentoot-devel] resurrect tbnl's debug-value macro?
In-Reply-To: <u4pmuiaeb.fsf@agharta.de>
References: <4877ae640705030114m40ede33ah864f5d2018755898@mail.gmail.com>
	<u4pmuiaeb.fsf@agharta.de>
Message-ID: <4877ae640705031039s695a9e90te16c25c9e90f3d61@mail.gmail.com>

On 5/3/07, Edi Weitz <edi at agharta.de> wrote:
> However, can't you have the same result if you add (BREAK) to your
> empty handler and set *CATCH-ERRORS-P* to NIL?  I think that
> *CATCH-ERRORS-P* is a superior replacement to *DEBUG-MODE* as you
> don't have to rely on your clients to not send more than one request.

You are right. If I were to debug a problem, *CATCH-ERRORS-P* and
break would be sufficient.

And I lied, I didn't use the REPL all that often :-)

It's ok for a simple function call but for sexp > 2 level deep I
prefer to use slime-scratch or work in the buffer directly and send
sexp with C-x C-e. It is much easier this way because I dont need to
recall history from the REPL and I have paredit and all the emacs
goodies that don't work in the REPL.

What really bother me is that a lot of code can't be call / test
interactively if any of the special variables are used (unbound
error).

Anyway, I have a simple work around now. This kind of stuff is really
easy with Lisp :-)

Thanks,
-- Mac


From emailmac at gmail.com  Thu May  3 17:46:37 2007
From: emailmac at gmail.com (Mac Chan)
Date: Thu, 3 May 2007 10:46:37 -0700
Subject: [hunchentoot-devel] resurrect tbnl's debug-value macro?
In-Reply-To: <20070503111748.GX16339@bateleur.arcanes.fr.eu.org>
References: <4877ae640705030114m40ede33ah864f5d2018755898@mail.gmail.com>
	<20070503111748.GX16339@bateleur.arcanes.fr.eu.org>
Message-ID: <4877ae640705031046j2150d5ddm45c0afab993eb99a@mail.gmail.com>

Hi Pierre,

On 5/3/07, Pierre THIERRY <nowhere.man at levallois.eu.org> wrote:
> The *debug-mode* behaviour won't scale,
> because you have to be sure there will only be a single HTTP request
> sent to the server, or the various variables will be overwritten.

While in development, I'll be the only person sending http request, so
this is a controlled environment. But this is really not the issue
though. For debugging what Edi suggested is the way to go.

> Just do it yourself, with a handler "leaking" the objects you want to
> inspect:
>
> (defvar *leak*)
>
> (defun leaking-handler ()
>   (setf *leak* (list *request* *reply*))
>   "<html><head><title>Leaked</title></head><body>Leaked.</body></html>")

No this won't solve the issue that I brought up.

If you test your handler in the REPL, it will complain that *response*
is not bound.

Your *leak* object won't do any good here, you'll have to manually
bind *request* to *leak* (and you can't automate this in your handler
because at that time *request* is dynamically bound and you cannot set
the global value of *request*)

But yeah there are other ways to do it. I just bring this up to see if
this is something that other hunchentoot users would want to have
built-in.

Regards,
-- Mac


From danielgackle at gmail.com  Thu May  3 18:35:38 2007
From: danielgackle at gmail.com (Daniel Gackle)
Date: Thu, 3 May 2007 12:35:38 -0600
Subject: [hunchentoot-devel] resurrect tbnl's debug-value macro?
In-Reply-To: <4877ae640705031046j2150d5ddm45c0afab993eb99a@mail.gmail.com>
References: <4877ae640705030114m40ede33ah864f5d2018755898@mail.gmail.com>
	<20070503111748.GX16339@bateleur.arcanes.fr.eu.org>
	<4877ae640705031046j2150d5ddm45c0afab993eb99a@mail.gmail.com>
Message-ID: <57952f8b0705031135i3bc248c0v357df9848c894e86@mail.gmail.com>

< But yeah there are other ways to do it. I just bring this up to see if
this is something that other hunchentoot users would want to have
built-in >

As mentioned, I did like having it in before. I tend to work in the REPL the
way you describe. I'm curious: when you say "there are other ways to do it,"
what do you have in mind?

Dan


On 5/3/07, Mac Chan <emailmac at gmail.com> wrote:
>
> Hi Pierre,
>
> On 5/3/07, Pierre THIERRY <nowhere.man at levallois.eu.org> wrote:
> > The *debug-mode* behaviour won't scale,
> > because you have to be sure there will only be a single HTTP request
> > sent to the server, or the various variables will be overwritten.
>
> While in development, I'll be the only person sending http request, so
> this is a controlled environment. But this is really not the issue
> though. For debugging what Edi suggested is the way to go.
>
> > Just do it yourself, with a handler "leaking" the objects you want to
> > inspect:
> >
> > (defvar *leak*)
> >
> > (defun leaking-handler ()
> >   (setf *leak* (list *request* *reply*))
> >   "<html><head><title>Leaked</title></head><body>Leaked.</body></html>")
>
> No this won't solve the issue that I brought up.
>
> If you test your handler in the REPL, it will complain that *response*
> is not bound.
>
> Your *leak* object won't do any good here, you'll have to manually
> bind *request* to *leak* (and you can't automate this in your handler
> because at that time *request* is dynamically bound and you cannot set
> the global value of *request*)
>
> But yeah there are other ways to do it. I just bring this up to see if
> this is something that other hunchentoot users would want to have
> built-in.
>
> Regards,
> -- Mac
> _______________________________________________
> 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/20070503/5f5781b6/attachment.html>

From emailmac at gmail.com  Thu May  3 19:31:39 2007
From: emailmac at gmail.com (Mac Chan)
Date: Thu, 3 May 2007 12:31:39 -0700
Subject: [hunchentoot-devel] resurrect tbnl's debug-value macro?
In-Reply-To: <57952f8b0705031135i3bc248c0v357df9848c894e86@mail.gmail.com>
References: <4877ae640705030114m40ede33ah864f5d2018755898@mail.gmail.com>
	<20070503111748.GX16339@bateleur.arcanes.fr.eu.org>
	<4877ae640705031046j2150d5ddm45c0afab993eb99a@mail.gmail.com>
	<57952f8b0705031135i3bc248c0v357df9848c894e86@mail.gmail.com>
Message-ID: <4877ae640705031231r7d0762aw22d5d5ac70bca11b@mail.gmail.com>

On 5/3/07, Daniel Gackle <danielgackle at gmail.com> wrote:
> I'm curious: when you say "there are other ways to do it," what do you have in mind?
>
> Dan

With this ugly bit of code. The debug-value macro is still nicer though :-)


(let ((saved-process-request #'hunchentoot::process-request)
      last-request last-session)

  (defun request-sniffer (request)
    (setf last-request request
          last-session *session*)
    (values))

  (defun enable-debug-mode ()
    (push #'request-sniffer *dispatch-table*)
    (setf (fdefinition 'hunchentoot::process-request)
          #'(lambda (&rest args)
              (prog1 (apply saved-process-request args)
                (setq *request* last-request
                      *session* last-session)))))

  (defun disable-debug-mode ()
    (makunbound '*request*)
    (makunbound '*session*)
    (setf last-request nil last-session nil
          *dispatch-table* (delete #'request-sniffer *dispatch-table*)
          (fdefinition 'hunchentoot::process-request) saved-process-request)))


From nowhere.man at levallois.eu.org  Fri May  4 02:16:37 2007
From: nowhere.man at levallois.eu.org (Pierre THIERRY)
Date: Fri, 4 May 2007 04:16:37 +0200
Subject: [hunchentoot-devel] resurrect tbnl's debug-value macro?
In-Reply-To: <4877ae640705031046j2150d5ddm45c0afab993eb99a@mail.gmail.com>
References: <4877ae640705030114m40ede33ah864f5d2018755898@mail.gmail.com>
	<20070503111748.GX16339@bateleur.arcanes.fr.eu.org>
	<4877ae640705031046j2150d5ddm45c0afab993eb99a@mail.gmail.com>
Message-ID: <20070504021636.GA25984@bateleur.arcanes.fr.eu.org>

Scribit Mac Chan dies 03/05/2007 hora 10:46:
> >Just do it yourself, with a handler "leaking" the objects you want to
> >inspect [...]
> No this won't solve the issue that I brought up.

You're right. I thought about it and the solution seemed too simple for
me not to try and code it cleanly. I've published the code under MIT
license here (that's a Mercurial repository):

http://arcanes.fr.eu.org/~pierre/2007/05/cl-leak/

Having an ASDF file is overkill, but at some point I thought I'd need
once-only from cl-utilities...

Basically, you'd use leak-variables as needed in a handler, and it would
store variables along with their names, so you can bind them to use them
later with with-leaked-variables:

(define-leak-variable *leak*)

(defun handler-to-debug ()
  (leak-variables *leak* *request* *reply* *session*)
  (do-some-hairy-stuff))

Then you trigger it from your browser, and you have an association list
in *leak* that you can use to bind the variables leaked:

(with-leaked-variables *leak*
  (handler-to-debug))

In a production environment, you could use leak-variables-once.

> But yeah there are other ways to do it. I just bring this up to see if
> this is something that other hunchentoot users would want to have
> built-in.

What bothers me in *debug-mode* is that even when you don't use it, it
might slightly slow down the server.

Quickly,
Pierre
-- 
nowhere.man at levallois.eu.org
OpenPGP 0xD9D50D8A
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20070504/129e5cd2/attachment.sig>

From emailmac at gmail.com  Fri May  4 04:02:21 2007
From: emailmac at gmail.com (Mac Chan)
Date: Thu, 3 May 2007 21:02:21 -0700
Subject: [hunchentoot-devel] resurrect tbnl's debug-value macro?
In-Reply-To: <20070504021636.GA25984@bateleur.arcanes.fr.eu.org>
References: <4877ae640705030114m40ede33ah864f5d2018755898@mail.gmail.com>
	<20070503111748.GX16339@bateleur.arcanes.fr.eu.org>
	<4877ae640705031046j2150d5ddm45c0afab993eb99a@mail.gmail.com>
	<20070504021636.GA25984@bateleur.arcanes.fr.eu.org>
Message-ID: <4877ae640705032102t7a28fe8ewc25e9a48aa6e3a76@mail.gmail.com>

Hi Pierre,

On 5/3/07, Pierre THIERRY <nowhere.man at levallois.eu.org> wrote:
> You're right. I thought about it and the solution seemed too simple for
> me not to try and code it cleanly. I've published the code under MIT
> license here (that's a Mercurial repository):
>
> Basically, you'd use leak-variables as needed in a handler, and it would
> store variables along with their names, so you can bind them to use them
> later with with-leaked-variables:
>
> (define-leak-variable *leak*)
>
> (defun handler-to-debug ()
>   (leak-variables *leak* *request* *reply* *session*)
>   (do-some-hairy-stuff))
>
> (with-leaked-variables *leak*
>   (handler-to-debug))

I don't want to keep going back to this topic but I find it
strange that you don't follow what my intention was because I
thought that's how everyone else write lisp code in a bottom up
style (paraphrase PG).

So using my previous toy example:

These are my sexp building blocks:

(session-value :selected-product)
(session-value :quantity)
(product-price (session-value :selected-product))
(* (session-value :quantity) (product-price (session-value :selected-product)))

What I want is to type these expressions in the REPL or in a
buffer, eval them and check the results. If they work fine, I can
put them together like LEGO and wrap them around a defun.

Now the problem is the dynamically bound variables.

Using your macro, my work flow would be:

(with-leaked-variables *leak*
  (session-value :selected-product))

(with-leaked-variables *leak*
  (session-value :quantity))

and then if they work, I need to cut the inner sexp and paste it
into the defun, how inconvenient!

What's more, that's not even the way that I prefer to write code.

Instead, I code up a defun that is not necessary working but then
I can test each of the inner sexps interactively.

(defun product-total-page (&optional (request *request*))
  (let ((p (session-value :selected-product)_1)
	(q (session-value :quantity)_2))
    (with-html
     (:html
      (:body
       (:table
	(:tr (:td "Product") (:td (str p)))
	(:tr (:td "Quantity") (:td (str q)))
	(:tr (:td "Total") (:td (str (* q (product-price p))))))))))_3)

What I do is that I place the cursor at the end of a sexp (marked
by _) that I want to test and send it to slime with c-x c-e

;; c-x c-e with cursor at _1
;; emacs message buffer shows
"T-Shirt XXL"

;; c-x c-e with cursor at _2
10

;; c-x c-e with cursor at _3
"<html><body>....</body></html>"

;; eval the following in the REPL
> (product-total-page)
=> "<html><body>....</body></html>"

The above example has no errors , but you can imagine that it
_evolves_ from a broken state to the working code.

Now if you require me to wrap every sexp with your
(with-leaked-variables) macro before I can test them, I think
I'll just give up and go back to perl or python or whatever (they
have libraries covering everything you want to write BTW ;-)

Regards,
-- Mac

(PS: Have you seen Marco Baringer's slime video?)


From nowhere.man at levallois.eu.org  Fri May  4 10:58:20 2007
From: nowhere.man at levallois.eu.org (Pierre THIERRY)
Date: Fri, 4 May 2007 12:58:20 +0200
Subject: [hunchentoot-devel] resurrect tbnl's debug-value macro?
In-Reply-To: <4877ae640705032102t7a28fe8ewc25e9a48aa6e3a76@mail.gmail.com>
References: <4877ae640705030114m40ede33ah864f5d2018755898@mail.gmail.com>
	<20070503111748.GX16339@bateleur.arcanes.fr.eu.org>
	<4877ae640705031046j2150d5ddm45c0afab993eb99a@mail.gmail.com>
	<20070504021636.GA25984@bateleur.arcanes.fr.eu.org>
	<4877ae640705032102t7a28fe8ewc25e9a48aa6e3a76@mail.gmail.com>
Message-ID: <20070504105820.GB25984@bateleur.arcanes.fr.eu.org>

Scribit Mac Chan dies 03/05/2007 hora 21:02:
> I find it strange that you don't follow what my intention was because
> I thought that's how everyone else write lisp code in a bottom up
> style

I really do both styles, bottom-up and top-down, so I really didn't
understand what you wanted to do.

> Now if you require me to wrap every sexp with your
> (with-leaked-variables) macro before I can test them, I think I'll
> just give up

Don't, your wish is just a macro away:

http://arcanes.fr.eu.org/~pierre/2007/05/cl-leak/?rev/dd3cb6ee7410

In your case, you'd still do (leak-variables *leak* ...) in a handler to
capture the various variables you need, and it's not restricted to
dynamic variables related to Hunchentoot. Then you'd evaluate
(setf-leaked-variables *leak*) in the REPL and you're in the exact
situation *debug-mode* was bringing you in.

Except it's now more flexible, and there's a conditional branching and a
cache miss that won't go in Hunchentoot's critical path.

Quickly,
Pierre
-- 
nowhere.man at levallois.eu.org
OpenPGP 0xD9D50D8A
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20070504/7e2262a7/attachment.sig>

From emailmac at gmail.com  Fri May  4 18:11:11 2007
From: emailmac at gmail.com (Mac Chan)
Date: Fri, 4 May 2007 11:11:11 -0700
Subject: [hunchentoot-devel] resurrect tbnl's debug-value macro?
In-Reply-To: <20070504105820.GB25984@bateleur.arcanes.fr.eu.org>
References: <4877ae640705030114m40ede33ah864f5d2018755898@mail.gmail.com>
	<20070503111748.GX16339@bateleur.arcanes.fr.eu.org>
	<4877ae640705031046j2150d5ddm45c0afab993eb99a@mail.gmail.com>
	<20070504021636.GA25984@bateleur.arcanes.fr.eu.org>
	<4877ae640705032102t7a28fe8ewc25e9a48aa6e3a76@mail.gmail.com>
	<20070504105820.GB25984@bateleur.arcanes.fr.eu.org>
Message-ID: <4877ae640705041111k4b631ee9v7e4ee4ed3f3441d1@mail.gmail.com>

On 5/4/07, Pierre THIERRY <nowhere.man at levallois.eu.org> wrote:
> Except it's now more flexible, and there's a conditional branching and a
> cache miss that won't go in Hunchentoot's critical path.

Not that I insist we put something something redundant into
Hunchentoot's critical path, as stated in my reply to Edi, I found a
workaround and I'm happy that I can go back to the way that I used to
work with tbnl. No complaints here.

But I find it funny that you repeatedly say that there _will_ be a
cache miss using the debug-value macro. How do you know? Maybe you
meant _potential_? I think it's incredibly painful to consider that
scenario when one is writing lisp code. Even with years of c
programming I have only come to see one or two examples of loop
unrolling at work.

Have you done any loop unrolling in lisp? (maybe lisp compiler is
smart enough to do that...) Do you declare all the types in your code?
I think most people come to lisp for fast prototyping and
implementation correctness. Lisp by default is fast enough for most
things.

> In your case, you'd still do (leak-variables *leak* ...) in a handler to
> capture the various variables you need, and it's not restricted to
> dynamic variables related to Hunchentoot. Then you'd evaluate
> (setf-leaked-variables *leak*) in the REPL and you're in the exact
> situation *debug-mode* was bringing you in.
>
> Don't, your wish is just a macro away:

No it isn't. You're creating more work for me. In my toy example if I
were to add a few more products in the cart using the browser, I'll
need to evaluate (setf-leaked-variables *leak*) to have it reflect in
*session*.

In fact I need to eval (setf-leaked-variables *leak*) everytime I
change something with the browser. That would take away all of fun,
wouldn't you agree?

-- Mac


From lispercat at gmail.com  Fri May  4 19:08:58 2007
From: lispercat at gmail.com (Andrei Stebakov)
Date: Fri, 4 May 2007 15:08:58 -0400
Subject: [hunchentoot-devel] resurrect tbnl's debug-value macro?
In-Reply-To: <4877ae640705041111k4b631ee9v7e4ee4ed3f3441d1@mail.gmail.com>
References: <4877ae640705030114m40ede33ah864f5d2018755898@mail.gmail.com>
	<20070503111748.GX16339@bateleur.arcanes.fr.eu.org>
	<4877ae640705031046j2150d5ddm45c0afab993eb99a@mail.gmail.com>
	<20070504021636.GA25984@bateleur.arcanes.fr.eu.org>
	<4877ae640705032102t7a28fe8ewc25e9a48aa6e3a76@mail.gmail.com>
	<20070504105820.GB25984@bateleur.arcanes.fr.eu.org>
	<4877ae640705041111k4b631ee9v7e4ee4ed3f3441d1@mail.gmail.com>
Message-ID: <affe56e00705041208s40fb28a9le807e04ba58cdc47@mail.gmail.com>

I agree with Mac. For me it's a question of "how much work I can do without
having to open the browser to test the functionality". Maybe it's a bad
design that I use, but I refer to the *session* variables not only from the
final *dispatch-table* function but from some intermediary ones too. That
means I can only test them by opening the web page. It would be great if I
could build the whole functionality from slime and only check the final
stage from the browser.

Andrew

On 5/4/07, Mac Chan <emailmac at gmail.com> wrote:
>
> On 5/4/07, Pierre THIERRY <nowhere.man at levallois.eu.org> wrote:
> > Except it's now more flexible, and there's a conditional branching and a
> > cache miss that won't go in Hunchentoot's critical path.
>
> Not that I insist we put something something redundant into
> Hunchentoot's critical path, as stated in my reply to Edi, I found a
> workaround and I'm happy that I can go back to the way that I used to
> work with tbnl. No complaints here.
>
> But I find it funny that you repeatedly say that there _will_ be a
> cache miss using the debug-value macro. How do you know? Maybe you
> meant _potential_? I think it's incredibly painful to consider that
> scenario when one is writing lisp code. Even with years of c
> programming I have only come to see one or two examples of loop
> unrolling at work.
>
> Have you done any loop unrolling in lisp? (maybe lisp compiler is
> smart enough to do that...) Do you declare all the types in your code?
> I think most people come to lisp for fast prototyping and
> implementation correctness. Lisp by default is fast enough for most
> things.
>
> > In your case, you'd still do (leak-variables *leak* ...) in a handler to
> > capture the various variables you need, and it's not restricted to
> > dynamic variables related to Hunchentoot. Then you'd evaluate
> > (setf-leaked-variables *leak*) in the REPL and you're in the exact
> > situation *debug-mode* was bringing you in.
> >
> > Don't, your wish is just a macro away:
>
> No it isn't. You're creating more work for me. In my toy example if I
> were to add a few more products in the cart using the browser, I'll
> need to evaluate (setf-leaked-variables *leak*) to have it reflect in
> *session*.
>
> In fact I need to eval (setf-leaked-variables *leak*) everytime I
> change something with the browser. That would take away all of fun,
> wouldn't you agree?
>
> -- Mac
> _______________________________________________
> 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/20070504/cbf256af/attachment.html>

From nowhere.man at levallois.eu.org  Fri May  4 19:13:54 2007
From: nowhere.man at levallois.eu.org (Pierre THIERRY)
Date: Fri, 4 May 2007 21:13:54 +0200
Subject: [hunchentoot-devel] resurrect tbnl's debug-value macro?
In-Reply-To: <4877ae640705041111k4b631ee9v7e4ee4ed3f3441d1@mail.gmail.com>
References: <4877ae640705030114m40ede33ah864f5d2018755898@mail.gmail.com>
	<20070503111748.GX16339@bateleur.arcanes.fr.eu.org>
	<4877ae640705031046j2150d5ddm45c0afab993eb99a@mail.gmail.com>
	<20070504021636.GA25984@bateleur.arcanes.fr.eu.org>
	<4877ae640705032102t7a28fe8ewc25e9a48aa6e3a76@mail.gmail.com>
	<20070504105820.GB25984@bateleur.arcanes.fr.eu.org>
	<4877ae640705041111k4b631ee9v7e4ee4ed3f3441d1@mail.gmail.com>
Message-ID: <20070504191354.GH25984@bateleur.arcanes.fr.eu.org>

Scribit Mac Chan dies 04/05/2007 hora 11:11:
> But I find it funny that you repeatedly say that there _will_ be a
> cache miss using the debug-value macro. How do you know? Maybe you
> meant _potential_?

Yeah, that was incorrect, that's only a possible cache miss.

> I think it's incredibly painful to consider that scenario when one is
> writing lisp code.

Well, you typically only have to worry about cache misses in the
critical path of some part of a system whose performance affect it as a
whole, like IPC in a ?-kernel or request handling in a network server,
it seems.

> Have you done any loop unrolling in lisp?

Not really. I only studied loop unrolling as I was a C++ programmer, and
C++ make it a pain, because you need black magic. Now that I begin to
understand Lisp's macros, I barely begin to imagine I could do easy and
efficient loop unrolling sometimes...

> Do you declare all the types in your code?  I think most people come
> to lisp for fast prototyping and implementation correctness. Lisp by
> default is fast enough for most things.

The critical path of my applications so far was always in underlying
libraries, like Hunchentoot or Elephant, so I never had the need to
profile and optimize my own code.

> In fact I need to eval (setf-leaked-variables *leak*) everytime I
> change something with the browser. That would take away all of fun,
> wouldn't you agree?

No, because it happened quite some times that I have to debug some part
of an application under stress, and then having the various debugging
variables rebound by each request would have been unacceptable.

If some people find this *debug-mode* really useful, though, it
shouldn't be that hard to write the switch not as a dynamic variable
(used much as a global variable, in this case) but as a function that
changes the various functions of Hunchentoot where the variables are
bound. When in a non-debug mode, it would store the debugging
alternatives, and in debug mode, it would store back the current ones...

Curiously,
Pierre
-- 
nowhere.man at levallois.eu.org
OpenPGP 0xD9D50D8A
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20070504/df1b22e8/attachment.sig>

From yoni-r at actcom.com  Fri May  4 19:44:21 2007
From: yoni-r at actcom.com (Yoni Rabkin Katzenell)
Date: Fri, 04 May 2007 22:44:21 +0300
Subject: [hunchentoot-devel] resurrect tbnl's debug-value macro?
In-Reply-To: <4877ae640705030114m40ede33ah864f5d2018755898@mail.gmail.com>
	(Mac Chan's message of "Thu, 3 May 2007 01:14:54 -0700")
References: <4877ae640705030114m40ede33ah864f5d2018755898@mail.gmail.com>
Message-ID: <8764781ii2.fsf@actcom.com>


I've been following the thread and thinking about why I'm not missing
debug-value even though I do a lot of prototyping on the REPL.

It seems that I tend to write small functions and extract information
from session variables as soon as possible, passing them on as functions
arguments. Therefore, it is always quite natural for me to write 99% of
the code without worrying about the particulars of what arrives from the
browser.

-- 
   "Cut your own wood and it will warm you twice"


From lam at tuxfamily.org  Mon May  7 16:01:42 2007
From: lam at tuxfamily.org (Nicolas Lamirault)
Date: Mon, 07 May 2007 18:01:42 +0200
Subject: [hunchentoot-devel] create-folder-dispatcher-and-handler question
Message-ID: <873b288vx5.fsf@no-log.org>


i try to use the create-folder-dispatcher-and-handler handler.
i creates like this :


[...]
(list (hunchentoot:create-folder-dispatcher-and-handler
      "/ernestine-radio/music/" *music-directory*))
[...]

*music-directory* corresponds to /opt/music/

so i make 2 http requests.
The first failed : 

[2007-05-07 17:53:41] 82.225.177.13 - "GET /ernestine-radio/music//f/Fatboy_Slim/Better%20Living%20Through%20Chemistry/10%20-%20The%20Sound%20Of%20Milwaukee.mp3 HTTP/1.1" 404 412 "-" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.3) Gecko/20070310 Iceweasel/2.0.0.3 (Debian-2.0.0.3-1)"

The second works well :

[2007-05-07 17:53:55] 82.225.177.13 - GET /ernestine-radio/music//b/Black_Rebel_Motorcycle_Club/BRMC/09.Spread_Your_Love.mp3 HTTP/1.1" 200 - "-" "Mozilla/5.0 (X11 ; U; Linux i686; en-US; rv:1.8.1.3) Gecko/20070310 Iceweasel/2.0.0.3 (Debian-2.0.0.3-1)"


i think the problem comes from the space in the name.
my requests are like this :

http://perave.dyndns.org:9090/ernestine-radio/music//f/Fatboy_Slim/Better Living Through Chemistry/10 - The Sound Of Milwaukee.mp3

the second :

http://perave.dyndns.org:9090/ernestine-radio/music//b/Black_Rebel_Motorcycle_Club/BRMC/09.Spread_Your_Love.mp3

so the second works well, not the first.
if i  try to url  encode the 2  requests, neither the one  neither the
second works.

Someone have any idea ?

Thanks for your help.


-- 
Nicolas Lamirault


From vsedach at gmail.com  Mon May  7 20:52:27 2007
From: vsedach at gmail.com (Vladimir Sedach)
Date: Mon, 7 May 2007 14:52:27 -0600
Subject: [hunchentoot-devel] *catch-errors-p* and spurious stream errors
	patch (add your own implementation and shake).
Message-ID: <c07e645b0705071352r57a22088oe2177c4f6052774f@mail.gmail.com>

Hello,

While debugging a web application, the need to not catch errors became
apparent. Unfortunately, there are spurious stream errors that make
this less than useful currently (someone has informed me that this
problem is well known). The attached patch is my proposal to let
people deal with this and take advantage of (setf *catch-errors-p*
nil). If you think this is the wrong way of going about things, please
let me know.

Thanks,
Vladimir
-------------- next part --------------
A non-text attachment was scrubbed...
Name: util.patch
Type: application/octet-stream
Size: 219 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20070507/484b6014/attachment.obj>

From edi at agharta.de  Mon May  7 22:05:49 2007
From: edi at agharta.de (Edi Weitz)
Date: Tue, 08 May 2007 00:05:49 +0200
Subject: [hunchentoot-devel] *catch-errors-p* and spurious stream errors
	patch (add your own implementation and shake).
In-Reply-To: <c07e645b0705071352r57a22088oe2177c4f6052774f@mail.gmail.com>
	(Vladimir Sedach's message of "Mon, 7 May 2007 14:52:27 -0600")
References: <c07e645b0705071352r57a22088oe2177c4f6052774f@mail.gmail.com>
Message-ID: <ud51cthky.fsf@agharta.de>

On Mon, 7 May 2007 14:52:27 -0600, "Vladimir Sedach" <vsedach at gmail.com> wrote:

> While debugging a web application, the need to not catch errors
> became apparent. Unfortunately, there are spurious stream errors
> that make this less than useful currently (someone has informed me
> that this problem is well known). The attached patch is my proposal
> to let people deal with this and take advantage of (setf
> *catch-errors-p* nil).

I had thought that the changes in 0.9.0 made the spurious time-out
errors go away.  Are you using the newest version?  Which errors do
you see exactly?  Can you send a backtrace?

> If you think this is the wrong way of going about things, please let
> me know.

If this is really still a problem, I'd like to release a patch for all
supported implementations.

Thanks,
Edi.


From edi at agharta.de  Mon May  7 22:22:10 2007
From: edi at agharta.de (Edi Weitz)
Date: Tue, 08 May 2007 00:22:10 +0200
Subject: [hunchentoot-devel] New release 0.9.3 (Was:
 create-folder-dispatcher-and-handler question)
In-Reply-To: <873b288vx5.fsf@no-log.org> (Nicolas Lamirault's message of
	"Mon, 07 May 2007 18:01:42 +0200")
References: <873b288vx5.fsf@no-log.org>
Message-ID: <u8xc0tgtp.fsf@agharta.de>

On Mon, 07 May 2007 18:01:42 +0200, Nicolas Lamirault <lam at tuxfamily.org> wrote:

> i think the problem comes from the space in the name.

Yes.  Seems this is a bug which was already in TBNL.  The new release
hopefully fixes that.

Thanks for the report,
Edi.


From nowhere.man at levallois.eu.org  Mon May  7 23:34:51 2007
From: nowhere.man at levallois.eu.org (Pierre THIERRY)
Date: Tue, 8 May 2007 01:34:51 +0200
Subject: [hunchentoot-devel] *catch-errors-p* and spurious stream errors
	patch (add your own implementation and shake).
In-Reply-To: <ud51cthky.fsf@agharta.de>
References: <c07e645b0705071352r57a22088oe2177c4f6052774f@mail.gmail.com>
	<ud51cthky.fsf@agharta.de>
Message-ID: <20070507233451.GA17561@bateleur.arcanes.fr.eu.org>

Scribit Edi Weitz dies 08/05/2007 hora 00:05:
> If this is really still a problem, I'd like to release a patch for all
> supported implementations.

I'm not sure why there would be a need to use an implementation specific
condition, as CL provides stream-error (which is a superclass of the
SBCL specific condition used in the patch).

diff -r 1ad0d5aa26ef packages.lisp
--- a/packages.lisp     Tue May 01 19:14:06 2007 +0200
+++ b/packages.lisp     Tue May 08 01:30:13 2007 +0200
@@ -131,6 +131,7 @@
            :+http-unsupported-media-type+
            :+http-use-proxy+
            :+http-version-not-supported+
+           :always-catch-stream-errors
            :authorization
            :aux-request-value
            :content-length
diff -r 1ad0d5aa26ef util.lisp
--- a/util.lisp Tue May 01 19:14:06 2007 +0200
+++ b/util.lisp Tue May 08 01:28:49 2007 +0200
@@ -100,10 +100,16 @@ are discarded \(that is, the body is an
                             `(let (,, at temps)
                               ,, at body))))))

-(defun maybe-invoke-debugger (condition)
-  "Invokes the debugger with CONDITION if *CATCH-ERRORS-P* is NIL."
+(defgeneric maybe-invoke-debugger (condition)
+  (:documentation "Invokes the debugger with CONDITION if *CATCH-ERRORS-P* is NIL."))
+
+(defmethod maybe-invoke-debugger (condition)
   (unless *catch-errors-p*
     (invoke-debugger condition)))
+
+(defun always-catch-stream-errors ()
+  (defmethod maybe-invoke-debugger :around ((condition stream-error))
+    nil))

 (defmacro with-debugger (&body body)
   "Executes BODY and invokes the debugger if an error is signaled and


But maybe that's still a quick and dirty fix for the problem. Maybe a
way to add and remove classes of conditions to catch would be better...

Doubtfully,
Pierre
-- 
nowhere.man at levallois.eu.org
OpenPGP 0xD9D50D8A
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20070508/1931f541/attachment.sig>

From nowhere.man at levallois.eu.org  Mon May  7 23:39:13 2007
From: nowhere.man at levallois.eu.org (Pierre THIERRY)
Date: Tue, 8 May 2007 01:39:13 +0200
Subject: [hunchentoot-devel] *catch-errors-p* and spurious stream errors
	patch (add your own implementation and shake).
In-Reply-To: <20070507233451.GA17561@bateleur.arcanes.fr.eu.org>
References: <c07e645b0705071352r57a22088oe2177c4f6052774f@mail.gmail.com>
	<ud51cthky.fsf@agharta.de>
	<20070507233451.GA17561@bateleur.arcanes.fr.eu.org>
Message-ID: <20070507233912.GB17561@bateleur.arcanes.fr.eu.org>

Oops, I didn't write a docstring for the new function:


diff -r 1ad0d5aa26ef packages.lisp
--- a/packages.lisp     Tue May 01 19:14:06 2007 +0200
+++ b/packages.lisp     Tue May 08 01:30:13 2007 +0200
@@ -131,6 +131,7 @@
            :+http-unsupported-media-type+
            :+http-use-proxy+
            :+http-version-not-supported+
+           :always-catch-stream-errors
            :authorization
            :aux-request-value
            :content-length
diff -r 1ad0d5aa26ef util.lisp
--- a/util.lisp Tue May 01 19:14:06 2007 +0200
+++ b/util.lisp Tue May 08 01:36:51 2007 +0200
@@ -100,10 +100,17 @@ are discarded \(that is, the body is an
                             `(let (,, at temps)
                               ,, at body))))))

-(defun maybe-invoke-debugger (condition)
-  "Invokes the debugger with CONDITION if *CATCH-ERRORS-P* is NIL."
+(defgeneric maybe-invoke-debugger (condition)
+  (:documentation "Invokes the debugger with CONDITION if *CATCH-ERRORS-P* is NIL."))
+
+(defmethod maybe-invoke-debugger (condition)
   (unless *catch-errors-p*
     (invoke-debugger condition)))
+
+(defun always-catch-stream-errors ()
+  "Adds an around method on MAYBE-INVOKE-DEBUGGER to always catch stream-related errors."
+  (defmethod maybe-invoke-debugger :around ((condition stream-error))
+    nil))

 (defmacro with-debugger (&body body)
   "Executes BODY and invokes the debugger if an error is signaled and


Correctively,
Pierre
-- 
nowhere.man at levallois.eu.org
OpenPGP 0xD9D50D8A
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20070508/c1467d4b/attachment.sig>

From edi at agharta.de  Tue May  8 06:17:31 2007
From: edi at agharta.de (Edi Weitz)
Date: Tue, 08 May 2007 08:17:31 +0200
Subject: [hunchentoot-devel] *catch-errors-p* and spurious stream errors
	patch (add your own implementation and shake).
In-Reply-To: <20070507233451.GA17561@bateleur.arcanes.fr.eu.org> (Pierre
	THIERRY's message of "Tue, 8 May 2007 01:34:51 +0200")
References: <c07e645b0705071352r57a22088oe2177c4f6052774f@mail.gmail.com>
	<ud51cthky.fsf@agharta.de>
	<20070507233451.GA17561@bateleur.arcanes.fr.eu.org>
Message-ID: <uzm4f4z5w.fsf@agharta.de>

On Tue, 8 May 2007 01:34:51 +0200, Pierre THIERRY <nowhere.man at levallois.eu.org> wrote:

> I'm not sure why there would be a need to use an implementation
> specific condition, as CL provides stream-error (which is a
> superclass of the SBCL specific condition used in the patch).

Agreed.

> +(defun always-catch-stream-errors ()
> +  (defmethod maybe-invoke-debugger :around ((condition stream-error))
> +    nil))

I think nesting a DEFMETHOD within a DEFUN is bad style.  There's also
no way to revoke this.

But, first of all, I'd like to wait for the OPs answers to my
questions anyway.

Thanks,
Edi.


From lam at tuxfamily.org  Tue May  8 12:01:08 2007
From: lam at tuxfamily.org (Nicolas Lamirault)
Date: Tue, 08 May 2007 14:01:08 +0200
Subject: [hunchentoot-devel] New release 0.9.3
In-Reply-To: <u8xc0tgtp.fsf@agharta.de>  (Edi Weitz's message of  "Tue\, 08 May
	2007 00\:22\:10 +0200")
References: <873b288vx5.fsf@no-log.org> <u8xc0tgtp.fsf@agharta.de>
Message-ID: <87abwfy16j.fsf@no-log.org>


hi,

Edi Weitz <edi at agharta.de> writes:

> On Mon, 07 May 2007 18:01:42 +0200, Nicolas Lamirault <lam at tuxfamily.org> wrote:
>
>> i think the problem comes from the space in the name.
>
> Yes.  Seems this is a bug which was already in TBNL.  The new release
> hopefully fixes that.

Yes ! Thanks for your great work !
My problem is solved.

> Thanks for the report,
> Edi.
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>

-- 
Nicolas Lamirault


From vsedach at gmail.com  Tue May  8 19:43:59 2007
From: vsedach at gmail.com (Vladimir Sedach)
Date: Tue, 8 May 2007 13:43:59 -0600
Subject: [hunchentoot-devel] *catch-errors-p* and spurious stream errors
	patch (add your own implementation and shake).
In-Reply-To: <uzm4f4z5w.fsf@agharta.de>
References: <c07e645b0705071352r57a22088oe2177c4f6052774f@mail.gmail.com>
	<ud51cthky.fsf@agharta.de>
	<20070507233451.GA17561@bateleur.arcanes.fr.eu.org>
	<uzm4f4z5w.fsf@agharta.de>
Message-ID: <c07e645b0705081243p4708877ahd72e5ae489de53c9@mail.gmail.com>

It turns out the error I'm getting is actually a
connection-reset-by-peer (although SBCL doesn't give the proper clues
for this - Allegro does). In fact it's a subtype of stream-error on
Allegro as well, so I think Pierre's approach to ignoring stream
errors is the right one.

The question that remains for me, is setting *catch-errors-p* to nil
the right way to debug applications built on Hunchentoot? It seems to
me the answer is 'yes', since they can potentially be tightly coupled
(for example, right now we're doing an :around on dispatch-request to
add functionality for our application). Making maybe-invoke-debugger a
generic function so you can specialize on the condition (ignore the
:around in my patch, I was being stupid) seems like an outgrowth of
this approach.

Vladimir

On 5/8/07, Edi Weitz <edi at agharta.de> wrote:
> On Tue, 8 May 2007 01:34:51 +0200, Pierre THIERRY <nowhere.man at levallois.eu.org> wrote:
>
> > I'm not sure why there would be a need to use an implementation
> > specific condition, as CL provides stream-error (which is a
> > superclass of the SBCL specific condition used in the patch).
>
> Agreed.
>
> > +(defun always-catch-stream-errors ()
> > +  (defmethod maybe-invoke-debugger :around ((condition stream-error))
> > +    nil))
>
> I think nesting a DEFMETHOD within a DEFUN is bad style.  There's also
> no way to revoke this.
>
> But, first of all, I'd like to wait for the OPs answers to my
> questions anyway.
>
> Thanks,
> Edi.
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>


From mifrai at hotmail.com  Wed May  9 04:12:16 2007
From: mifrai at hotmail.com (Micheal Fria)
Date: Tue, 08 May 2007 21:12:16 -0700
Subject: [hunchentoot-devel] Managing Deployment of Lisp Web Apps?
Message-ID: <BAY106-F25C23C0DE2DCA7B0479B14D73B0@phx.gbl>

Hi,

I'm relatively new to the whole paradigm of having a constantly running core 
image so this question may come of as a little dumb. So please forgive me if 
I do.

I was wondering what is the generally accepted best method of deployment for 
hunchentoot websites? (ie. how would one go about moving it from 
staging/testing server to the live/primary server?)

I'm used to working in the LAMP environment where it's just copying the 
needed files -- and I've been doing the same thing in the same fashion - 
except instead of files it's functions being transfered via swank...

But there's got to be a better way! I'm running into problems where I'm 
forgetting to update a function. (I'm also a tad bit of a neat freak and 
don't like having abandoned/orphaned functions lying around that do 
nothing).

Any suggestions? How are you guys managing deployment of your software? I 
look forward to what you guys have to say.

Thanks,
- Micheal Frai

_________________________________________________________________
See what you?re getting into?before you go there 
http://newlivehotmail.com/?ocid=TXT_TAGHM_migration_HM_viral_preview_0507



From emailmac at gmail.com  Wed May  9 04:52:18 2007
From: emailmac at gmail.com (Mac Chan)
Date: Tue, 8 May 2007 21:52:18 -0700
Subject: [hunchentoot-devel] Managing Deployment of Lisp Web Apps?
In-Reply-To: <BAY106-F25C23C0DE2DCA7B0479B14D73B0@phx.gbl>
References: <BAY106-F25C23C0DE2DCA7B0479B14D73B0@phx.gbl>
Message-ID: <4877ae640705082152y376e66d7j9a397cbb37118479@mail.gmail.com>

> I'm used to working in the LAMP environment where it's just copying the
> needed files

You can still copy the files over. However, I prefer to use source
control to sync up the files instead of using scp/ftp, etc.

> and I've been doing the same thing in the same fashion -
> except instead of files it's functions being transfered via swank...

Assuming that you are using asdf for your project, you can just type
,load-system in slime REPL to reload your modified files.

I usually have gnu screen running and dedicate one terminal for my
lisp's REPL (not slime).

When I need slime (for debugging), I just type (swank:CREATE-SERVER)
and then I can connect from emacs.

HTH,
-- Mac


From austin at pettomato.com  Wed May  9 19:28:08 2007
From: austin at pettomato.com (Austin Haas)
Date: Wed, 9 May 2007 15:28:08 -0400
Subject: [hunchentoot-devel] Managing Deployment of Lisp Web Apps?
In-Reply-To: <4877ae640705082152y376e66d7j9a397cbb37118479@mail.gmail.com>
References: <BAY106-F25C23C0DE2DCA7B0479B14D73B0@phx.gbl>
	<4877ae640705082152y376e66d7j9a397cbb37118479@mail.gmail.com>
Message-ID: <20070509192808.GA11788@bean.chicago>


I've been using darcs to "push" the new files to the server. Then I ssh to the server and make a new core image, with a script like this (sbcl):

(asdf:oos 'asdf:load-op 'swank)
(asdf:oos 'asdf:load-op :pettomato)

(defun my-toplevel()
  ;; start swank
	(setf swank:*use-dedicated-output-stream* nil)
	(setf swank:*communication-style* :fd-handler)
  (swank:create-server :dont-close t)

	;; start hunchentoot
	(pettomato:start)

  ;; start a repl
  (sb-impl::toplevel-repl nil))

(sb-ext:save-lisp-and-die "pettomato.core" :toplevel #'my-toplevel)

"pettomato" is the name of my website package.

Then I kill the previously running image, and start a new one running in a screen session with this script:

#!/bin/sh
screen -dmS pettomato-site sbcl --core /home/astro/bin/pettomato.core --noinform

The main reason that I do it this way is because I have init scripts that launch the above script at boot time. This way it will be up-to-date and load quickly if the server reboots.

I don't update the production server very often, so this works well for me. If anyone sees any flaws with this logic, please let me know.

-austin

-- 
Austin Haas
Pet Tomato, Inc.
http://pettomato.com

On Tue May 08 21:52 , Mac Chan wrote:
> > I'm used to working in the LAMP environment where it's just copying the
> > needed files
> 
>  You can still copy the files over. However, I prefer to use source
>  control to sync up the files instead of using scp/ftp, etc.
> 
> > and I've been doing the same thing in the same fashion -
> > except instead of files it's functions being transfered via swank...
> 
>  Assuming that you are using asdf for your project, you can just type
>  ,load-system in slime REPL to reload your modified files.
> 
>  I usually have gnu screen running and dedicate one terminal for my
>  lisp's REPL (not slime).
> 
>  When I need slime (for debugging), I just type (swank:CREATE-SERVER)
>  and then I can connect from emacs.
> 
>  HTH,
>  -- Mac
>  _______________________________________________
>  tbnl-devel site list
>  tbnl-devel at common-lisp.net
>  http://common-lisp.net/mailman/listinfo/tbnl-devel
> 


From nowhere.man at levallois.eu.org  Thu May 10 11:28:57 2007
From: nowhere.man at levallois.eu.org (Pierre THIERRY)
Date: Thu, 10 May 2007 13:28:57 +0200
Subject: [hunchentoot-devel] Managing Deployment of Lisp Web Apps?
In-Reply-To: <BAY106-F25C23C0DE2DCA7B0479B14D73B0@phx.gbl>
References: <BAY106-F25C23C0DE2DCA7B0479B14D73B0@phx.gbl>
Message-ID: <20070510112857.GD13184@bateleur.arcanes.fr.eu.org>

Scribit Micheal Fria dies 08/05/2007 hora 21:12:
> I'm relatively new to the whole paradigm of having a constantly
> running core image

You'll find that paradigm definitely interesting. As I'm fairly new to
it myself, I couldn't conclude that it's better in any way, except that
I like it more than the other ones, and that it seems to me it opens the
door to much more scenarios (notably in terms of security and access
control, as you have total control on the environment and permissions of
the Lisp image).

> so this question may come of as a little dumb. So please forgive me if
> I do.

A new paradigm opens up new questions...

> I was wondering what is the generally accepted best method of
> deployment for hunchentoot websites? (ie. how would one go about
> moving it from staging/testing server to the live/primary server?)

I didn't see any best practice published by anyone, but I suspect that
many of us manage the code under a revision control and use that to move
the source code of a stable revision to the production system.

As far as running the image is concerned, I also suspect many of us run
it in some detachable tty. I use screen because I also use it locally to
keep a dozen of terminals open, some prefer more lightweight solutions
like detachtty.

> But there's got to be a better way! I'm running into problems where
> I'm forgetting to update a function.

I usually have a startup Lisp file or/along with a shell script that
loads the ASDF system and starts the server. To be sure my hot updates
of code didn't introduce any bootstrap issues, I can just restart the
server with that (or do it in parallel, to keep the image running).

Personaly,
Pierre
-- 
nowhere.man at levallois.eu.org
OpenPGP 0xD9D50D8A
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20070510/8cda9550/attachment.sig>

From masm at acm.org  Thu May 10 23:23:08 2007
From: masm at acm.org (Marco Monteiro)
Date: Fri, 11 May 2007 00:23:08 +0100
Subject: [hunchentoot-devel] Chunking disabled in ssl servers.
Message-ID: <4643A95C.7080908@acm.org>

In the function START-SERVER, output chunking is explicitly disabled for
SSL connections. Why? Is there any problem in using chunking with SSL?

Marco



From edi at agharta.de  Fri May 11 07:08:50 2007
From: edi at agharta.de (Edi Weitz)
Date: Fri, 11 May 2007 09:08:50 +0200
Subject: [hunchentoot-devel] Chunking disabled in ssl servers.
In-Reply-To: <4643A95C.7080908@acm.org> (Marco Monteiro's message of "Fri,
	11 May 2007 00:23:08 +0100")
References: <4643A95C.7080908@acm.org>
Message-ID: <u7irfj0ql.fsf@agharta.de>

On Fri, 11 May 2007 00:23:08 +0100, Marco Monteiro <masm at acm.org> wrote:

> In the function START-SERVER, output chunking is explicitly disabled
> for SSL connections. Why? Is there any problem in using chunking
> with SSL?

To be honest - I never bothered to try.  ISTR that (Portable)
AllegroServe disables chunking for SSL connections and I probably just
mimicked that behaviour.

Feel free to play around without chunking disabled.  If you have
enough evidence that SSL works flawlessly with chunking (across
different Lisps and operating systems), I'll be happy to remove the
code which disables it from Hunchentoot.

Cheers,
Edi.


From ocorrain at gmail.com  Fri May 11 14:46:02 2007
From: ocorrain at gmail.com (Tiarnan O'Corrain)
Date: Fri, 11 May 2007 15:46:02 +0100
Subject: [hunchentoot-devel] HTTP PUT and DELETE
Message-ID: <ea7fafc0705110746o593abdb8w34d5cc0b4b12e94@mail.gmail.com>

Hi--

does Hunchentoot support these, and if not, would it take much effort
to implement them?  Anyone else interested?

regards

Tiarn?n


From xach at xach.com  Fri May 11 14:48:06 2007
From: xach at xach.com (Zach Beane)
Date: Fri, 11 May 2007 10:48:06 -0400
Subject: [hunchentoot-devel] HTTP PUT and DELETE
In-Reply-To: <ea7fafc0705110746o593abdb8w34d5cc0b4b12e94@mail.gmail.com>
References: <ea7fafc0705110746o593abdb8w34d5cc0b4b12e94@mail.gmail.com>
Message-ID: <20070511144806.GH30872@xach.com>

On Fri, May 11, 2007 at 03:46:02PM +0100, Tiarnan O'Corrain wrote:
> Hi--
> 
> does Hunchentoot support these, and if not, would it take much effort
> to implement them?  Anyone else interested?

You can do pretty much whatever you want by looking at
hunchentoot:request-method and (for PUT) hunchentoot:raw-post-data.

Zach


From edi at agharta.de  Fri May 11 15:04:23 2007
From: edi at agharta.de (Edi Weitz)
Date: Fri, 11 May 2007 17:04:23 +0200
Subject: [hunchentoot-devel] HTTP PUT and DELETE
In-Reply-To: <ea7fafc0705110746o593abdb8w34d5cc0b4b12e94@mail.gmail.com>
	(Tiarnan O'Corrain's message of "Fri, 11 May 2007 15:46:02 +0100")
References: <ea7fafc0705110746o593abdb8w34d5cc0b4b12e94@mail.gmail.com>
Message-ID: <ups57fll4.fsf@agharta.de>

On Fri, 11 May 2007 15:46:02 +0100, "Tiarnan O'Corrain" <ocorrain at gmail.com> wrote:

> does Hunchentoot support these, and if not, would it take much
> effort to implement them?

You can look at how CL-WEBDAV does it:

  http://weitz.de/cl-webdav/

There's no special support from Hunchentoot necessary.

> Anyone else interested?

What do you want to use it for?


From coffeemug at gmail.com  Fri May 11 18:57:20 2007
From: coffeemug at gmail.com (Slava Akhmechet)
Date: Fri, 11 May 2007 14:57:20 -0400
Subject: [hunchentoot-devel] Can't write to FD-STREAM: Broken pipe
Message-ID: <87tzuj9oj3.fsf@gmail.com>

I'm looking through the Hunchetoot log and occassionally I see the
following messages:

[2007-05-11 14:50:37 [ERROR]] Error while processing connection:
                                     couldn't write to
                                     #<SB-SYS:FD-STREAM for "a
                                     constant string" {BA242B1}>:
                                     Connection reset by peer

[2007-05-11 14:50:37 [ERROR]] Error while processing connection:
                                     couldn't write to
                                     #<SB-SYS:FD-STREAM for "a
                                     constant string" {BDF02B1}>:
                                     Broken pipe

I don't see any problems in the browser, I only found out about these
messages because I looked at the log. Can someone think of a situation
in which these errors would occur without interrupting user
experience and why?

-- 
Regards,
Slava Akhmechet.


From edi at agharta.de  Fri May 11 19:45:03 2007
From: edi at agharta.de (Edi Weitz)
Date: Fri, 11 May 2007 21:45:03 +0200
Subject: [hunchentoot-devel] Can't write to FD-STREAM: Broken pipe
In-Reply-To: <87tzuj9oj3.fsf@gmail.com> (Slava Akhmechet's message of "Fri,
	11 May 2007 14:57:20 -0400")
References: <87tzuj9oj3.fsf@gmail.com>
Message-ID: <ulkfvf8lc.fsf@agharta.de>

On Fri, 11 May 2007 14:57:20 -0400, Slava Akhmechet <coffeemug at gmail.com> wrote:

> I'm looking through the Hunchetoot log and occassionally I see the
> following messages:
>
> [2007-05-11 14:50:37 [ERROR]] Error while processing connection:
>                                      couldn't write to
>                                      #<SB-SYS:FD-STREAM for "a
>                                      constant string" {BA242B1}>:
>                                      Connection reset by peer
>
> [2007-05-11 14:50:37 [ERROR]] Error while processing connection:
>                                      couldn't write to
>                                      #<SB-SYS:FD-STREAM for "a
>                                      constant string" {BDF02B1}>:
>                                      Broken pipe
>
> I don't see any problems in the browser, I only found out about
> these messages because I looked at the log. Can someone think of a
> situation in which these errors would occur without interrupting
> user experience and why?

The user pressed "Stop" or went to another website before the page
(including all images and other stuff) was fully loaded.  "Broken
pipe" and "Connection reset by peer" are pretty common error messages
you'll find (for example) in every Apache logfile - this is nothing
specific to Hunchentoot or Lisp.

HTH,
Edi.


From edi at agharta.de  Fri May 11 22:37:00 2007
From: edi at agharta.de (Edi Weitz)
Date: Sat, 12 May 2007 00:37:00 +0200
Subject: [hunchentoot-devel] New release 0.10.0 (Was: *catch-errors-p* and
 spurious stream
 errors patch (add your own implementation and shake).)
In-Reply-To: <c07e645b0705081243p4708877ahd72e5ae489de53c9@mail.gmail.com>
	(Vladimir Sedach's message of "Tue, 8 May 2007 13:43:59 -0600")
References: <c07e645b0705071352r57a22088oe2177c4f6052774f@mail.gmail.com>
	<ud51cthky.fsf@agharta.de>
	<20070507233451.GA17561@bateleur.arcanes.fr.eu.org>
	<uzm4f4z5w.fsf@agharta.de>
	<c07e645b0705081243p4708877ahd72e5ae489de53c9@mail.gmail.com>
Message-ID: <ubqgroulv.fsf_-_@agharta.de>

On Tue, 8 May 2007 13:43:59 -0600, "Vladimir Sedach" <vsedach at gmail.com> wrote:

> Making maybe-invoke-debugger a generic function so you can
> specialize on the condition (ignore the :around in my patch, I was
> being stupid) seems like an outgrowth of this approach.

Yes, that makes sense.  I've made a new release where
MAYBE-INVOKE-DEBUGGER is an exported generic function.

Thanks,
Edi.


From victor.kryukov at gmail.com  Sun May 13 08:10:55 2007
From: victor.kryukov at gmail.com (Victor Kryukov)
Date: Sun, 13 May 2007 03:10:55 -0500
Subject: [hunchentoot-devel] A typo in Hunchentoot doc?
Message-ID: <e7cab2390705130110sf796d0k52ffea4ccd2d321b@mail.gmail.com>

Fourth paragraph of define-easy-handler documentation reads:

The resulting handler will be a Lisp function with the name name and
keyword parameters named by the var symbols. Each var will be bound to
the value of the GET or POST parameter called real-name (a string)
before the body of the function is executed. If real-name is not
provided, it will be computed by downcasing the symbol name of name.

It seems to me that last 'name' should be replace by 'var'.

Regards,
Victor.

-- 
Yours Sincerely,
Victor Kryukov


From edi at agharta.de  Wed May 16 09:19:50 2007
From: edi at agharta.de (Edi Weitz)
Date: Wed, 16 May 2007 11:19:50 +0200
Subject: [hunchentoot-devel] A typo in Hunchentoot doc?
In-Reply-To: <e7cab2390705130110sf796d0k52ffea4ccd2d321b@mail.gmail.com>
	(Victor Kryukov's message of "Sun, 13 May 2007 03:10:55 -0500")
References: <e7cab2390705130110sf796d0k52ffea4ccd2d321b@mail.gmail.com>
Message-ID: <uhcqdktvt.fsf@agharta.de>

On Sun, 13 May 2007 03:10:55 -0500, "Victor Kryukov" <victor.kryukov at gmail.com> wrote:

> It seems to me that last 'name' should be replace by 'var'.

Yes, you're right.  I've updated the website and will include the fix
in the next release.

Thanks,
Edi.


From penguin at ocean.vvo.ru  Wed May 16 09:55:18 2007
From: penguin at ocean.vvo.ru (Igor Plekhov)
Date: Wed, 16 May 2007 20:55:18 +1100
Subject: [hunchentoot-devel] A typo in Hunchentoot doc?
In-Reply-To: <e7cab2390705130110sf796d0k52ffea4ccd2d321b@mail.gmail.com>
References: <e7cab2390705130110sf796d0k52ffea4ccd2d321b@mail.gmail.com>
Message-ID: <20070516095518.GQ15416@ocean.vvo.ru>

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

TNBL supports sessions: ...
^^^^ another typo


--
Registered Linux User #124759


From edi at agharta.de  Wed May 16 10:06:39 2007
From: edi at agharta.de (Edi Weitz)
Date: Wed, 16 May 2007 12:06:39 +0200
Subject: [hunchentoot-devel] A typo in Hunchentoot doc?
In-Reply-To: <20070516095518.GQ15416@ocean.vvo.ru> (Igor Plekhov's message
	of "Wed, 16 May 2007 20:55:18 +1100")
References: <e7cab2390705130110sf796d0k52ffea4ccd2d321b@mail.gmail.com>
	<20070516095518.GQ15416@ocean.vvo.ru>
Message-ID: <u8xbpkrps.fsf@agharta.de>

On Wed, 16 May 2007 20:55:18 +1100, Igor Plekhov <penguin at ocean.vvo.ru> wrote:

> http://weitz.de/hunchentoot/#sessions
>
> TNBL supports sessions: ...
> ^^^^ another typo

Ah, right.  I had searched the document for "TBNL", but obviously not
for "TNBL"... :)

Thanks,
Edi.


From info at jensteich.de  Wed May 16 10:24:45 2007
From: info at jensteich.de (Jens Teich)
Date: Wed, 16 May 2007 12:24:45 +0200
Subject: [hunchentoot-devel] A typo in Hunchentoot doc?
References: <e7cab2390705130110sf796d0k52ffea4ccd2d321b@mail.gmail.com><20070516095518.GQ15416@ocean.vvo.ru>
	<u8xbpkrps.fsf@agharta.de>
Message-ID: <010701c797a4$70616410$6602a8c0@JensSony>

Edi Weitz wrote:
> On Wed, 16 May 2007 20:55:18 +1100, Igor Plekhov
> <penguin at ocean.vvo.ru> wrote: 
> 
>> http://weitz.de/hunchentoot/#sessions
>> 
>> TNBL supports sessions: ...
>> ^^^^ another typo
> 
> Ah, right.  I had searched the document for "TBNL", but obviously not
> for "TNBL"... :)

has to be corrected into HNUCHENTOOT for compatibility :)

Jens


From ocorrain at gmail.com  Wed May 16 11:07:31 2007
From: ocorrain at gmail.com (Tiarnan O'Corrain)
Date: Wed, 16 May 2007 12:07:31 +0100
Subject: [hunchentoot-devel] A typo in Hunchentoot doc?
In-Reply-To: <010701c797a4$70616410$6602a8c0@JensSony>
References: <e7cab2390705130110sf796d0k52ffea4ccd2d321b@mail.gmail.com>
	<20070516095518.GQ15416@ocean.vvo.ru> <u8xbpkrps.fsf@agharta.de>
	<010701c797a4$70616410$6602a8c0@JensSony>
Message-ID: <ea7fafc0705160407q7aa6fe11odb4b8e615c4757a9@mail.gmail.com>

Apologies if this is a FAQ, but Edi, do you automate the creation
of the docs in any way?

regards

Tiarn?n


From edi at agharta.de  Wed May 16 11:11:52 2007
From: edi at agharta.de (Edi Weitz)
Date: Wed, 16 May 2007 13:11:52 +0200
Subject: [hunchentoot-devel] A typo in Hunchentoot doc?
In-Reply-To: <ea7fafc0705160407q7aa6fe11odb4b8e615c4757a9@mail.gmail.com>
	(Tiarnan O'Corrain's message of "Wed, 16 May 2007 12:07:31 +0100")
References: <e7cab2390705130110sf796d0k52ffea4ccd2d321b@mail.gmail.com>
	<20070516095518.GQ15416@ocean.vvo.ru> <u8xbpkrps.fsf@agharta.de>
	<010701c797a4$70616410$6602a8c0@JensSony>
	<ea7fafc0705160407q7aa6fe11odb4b8e615c4757a9@mail.gmail.com>
Message-ID: <u4pmdkop3.fsf@agharta.de>

On Wed, 16 May 2007 12:07:31 +0100, "Tiarnan O'Corrain" <ocorrain at gmail.com> wrote:

> Apologies if this is a FAQ, but Edi, do you automate the creation of
> the docs in any way?

Half-heartedly:

  http://weitz.de/documentation-template/


From coffeemug at gmail.com  Wed May 16 13:26:53 2007
From: coffeemug at gmail.com (Vyacheslav Akhmechet)
Date: Wed, 16 May 2007 09:26:53 -0400
Subject: [hunchentoot-devel] ACL case sensitive reader incompatibilities
Message-ID: <b381ea40705160626p10af5ae6y95a39002444a42d7@mail.gmail.com>

I seem to run into some issues with Hunchentoot on ACL due to case
sensitivity. When I turn case sensitivity off using '(set-case-mode
:case-insensitive-upper)', everything behaves as expected. However,
when I run in ACL's default mode, some things don't seem to work. Here
is a list of issues I run into without the case-mode fix:

1. Loading Hunchentoot with asdf throws me into a debugger saying I
need a newer version of TRIVIAL-GRAY-STREAMS. If I choose to continue
at this point, I get another error in the debugger saying "Package
:flexi-streams does not exist." When I choose an option to create it
anyway, Hunchentoot loads fine.

2. (request-method) function returns symbols in the "incorrect" case -
:GET and :POST, intead of :get and :post. This means it's not possible
to simply compare symbols (using ecase, for example) - it becomes
necessary to compare their names (with a case insensitive string
comparison). Franz gives guidelines on how to write software that runs
both on case sensitive and case insensitive implementations here:
http://www.franz.com/support/documentation/5.0.1/doc/cl/case.htm. Are
these being used by Hunchentoot?

3. Sessions/parameters don't seem to work properly. URL rewriting
works, however it looks like the cookie functionality does not work.
Additionally, (post-parameters) always returns nil on POST requests -
effectively it's only possible to operate in GET mode.

I'm not sure if Hunchentoot is meant to support ACL in its default
reader mode, so I thought I'd report these issues.

Regards,
- Slava Akhmechet


From edi at agharta.de  Wed May 16 13:49:27 2007
From: edi at agharta.de (Edi Weitz)
Date: Wed, 16 May 2007 15:49:27 +0200
Subject: [hunchentoot-devel] ACL case sensitive reader incompatibilities
In-Reply-To: <b381ea40705160626p10af5ae6y95a39002444a42d7@mail.gmail.com>
	(Vyacheslav
	Akhmechet's message of "Wed, 16 May 2007 09:26:53 -0400")
References: <b381ea40705160626p10af5ae6y95a39002444a42d7@mail.gmail.com>
Message-ID: <u4pmckheg.fsf@agharta.de>

Hi,

On Wed, 16 May 2007 09:26:53 -0400, "Vyacheslav Akhmechet" <coffeemug at gmail.com> wrote:

> Franz gives guidelines on how to write software that runs both on
> case sensitive and case insensitive implementations here:
> http://www.franz.com/support/documentation/5.0.1/doc/cl/case.htm. Are
> these being used by Hunchentoot?

No.

> I'm not sure if Hunchentoot is meant to support ACL in its default
> reader mode, so I thought I'd report these issues.

Currently it is not.  My take on this is that AllegroCL's "modern
mode" is not ANSI-compliant and thus nothing to lose sleep over.  I
have never used it and probably never will.

I'd be willing to accept clean[*] patches to make Hunchentoot work
with "modern mode", but only if they don't make the code more
complicated or less flexible and general.

Cheers,
Edi.


[*] http://weitz.de/patches.html


From emailmac at gmail.com  Fri May 18 21:56:29 2007
From: emailmac at gmail.com (Mac Chan)
Date: Fri, 18 May 2007 14:56:29 -0700
Subject: [hunchentoot-devel] per server easy-handler-alist
Message-ID: <4877ae640705181456o25516e5aid5ca0d4fc257ce66@mail.gmail.com>

Since Edit added the ultra-flexible macro define-easy-handler, I have
replaced all my custom dispatch functions with it.

There's a small issue with this macro, since it modifies the global
*easy-handler-alist*.

In production I have two server instances, one http and one https.

I cannot easily say, for example, I want the following apply only to
the https server instance.

(define-easy-handler (home-page :uri "/login") ()
  (with-html ...))

(define-easy-handler (home-page :uri "/my-account") ()
  (with-html ...))


The problem is that start-server happens at run-time but
define-easy-handler happens at load-time, so you cannot associate any
server specific binding in define-easy-handler.

Attached is a patch that introduce a slot :name to the server class
and a global variable *servers* which is an a-list mapping names to
server instances.

With this you can do something like

(define-easy-handler (home-page :uri "/hunchentoot/test/easy-home.html"
                                :server-names '(:http))
    ()
  (with-html (:html (:body "Home page"))))

(define-easy-handler (login-page :uri "/hunchentoot/test/easy-login.html"
                                 :server-names '(:https))
    ()
  (with-html (:html (:body "Secure login"))))

(define-easy-handler (common-page :uri "/hunchentoot/test/easy-common.html"
                                  :server-names '(:https :http))
    ()
  (with-html (:html (:body "Common page"))))

(start-server :name :http :port 8000)
(stop-server :http)

(start-server :name :https :port 4443)
(stop-server :https)

If you are not using multiple servers, this change will be transparent.

I'd appreciate any suggestions.

Regards,
-- Mac


From edi at agharta.de  Fri May 18 22:06:12 2007
From: edi at agharta.de (Edi Weitz)
Date: Sat, 19 May 2007 00:06:12 +0200
Subject: [hunchentoot-devel] per server easy-handler-alist
In-Reply-To: <4877ae640705181456o25516e5aid5ca0d4fc257ce66@mail.gmail.com> (Mac
	Chan's message of "Fri, 18 May 2007 14:56:29 -0700")
References: <4877ae640705181456o25516e5aid5ca0d4fc257ce66@mail.gmail.com>
Message-ID: <u646plrcb.fsf@agharta.de>

On Fri, 18 May 2007 14:56:29 -0700, "Mac Chan" <emailmac at gmail.com> wrote:

> Since Edit added the ultra-flexible macro define-easy-handler, I
> have replaced all my custom dispatch functions with it.

Edit.  Hmm...  You're not the first one.  Maybe I should change my
name... :)

> Attached is a patch that introduce a slot :name to the server class
> and a global variable *servers* which is an a-list mapping names to
> server instances.

I think you forgot the patch.

> I'd appreciate any suggestions.

At a first glance, this seems like a useful change to me.  I have to
think about it a bit more.


From emailmac at gmail.com  Fri May 18 22:45:21 2007
From: emailmac at gmail.com (Mac Chan)
Date: Fri, 18 May 2007 15:45:21 -0700
Subject: [hunchentoot-devel] per server easy-handler-alist
In-Reply-To: <u646plrcb.fsf@agharta.de>
References: <4877ae640705181456o25516e5aid5ca0d4fc257ce66@mail.gmail.com>
	<u646plrcb.fsf@agharta.de>
Message-ID: <4877ae640705181545y71dd58f5y9e449b7154b1779d@mail.gmail.com>

On 5/18/07, Edi Weitz <edi at agharta.de> wrote:
> Edit.  Hmm...  You're not the first one.  Maybe I should change my
> name... :)

I have an excuse - google didn't flag any spelling errors :-)

> > Attached is a patch that introduce a slot :name to the server class
> > and a global variable *servers* which is an a-list mapping names to
> > server instances.
>
> I think you forgot the patch.
Oops.

> > I'd appreciate any suggestions.
>
> At a first glance, this seems like a useful change to me.  I have to
> think about it a bit more.

Of course it would be best if you do the refactoring (provided that
you have time), the result is probably optimal.

Anyway, you can take a look at the patch and see if it is useful.

Thanks!
-- Mac
-------------- next part --------------
Index: doc/index.html
===================================================================
--- doc/index.html	(revision 1242)
+++ doc/index.html	(working copy)
@@ -316,10 +316,11 @@
 several servers in one image, each one listening to a different port.
 
 <p><br>[Function]
-<br><a class=none name="start-server"><b>start-server</b> <i><tt>&amp;key</tt> port address dispatch-table mod-lisp-p use-apache-log-p input-chunking-p read-timeout write-timeout setuid setgid ssl-certificate-file ssl-privatekey-file ssl-privatekey-password</i> =&gt; <i>server</i></a>
+<br><a class=none name="start-server"><b>start-server</b> <i><tt>&amp;key</tt>name port address dispatch-table mod-lisp-p use-apache-log-p input-chunking-p read-timeout write-timeout setuid setgid ssl-certificate-file ssl-privatekey-file ssl-privatekey-password</i> =&gt; <i>server</i></a>
 
-<blockquote><br> Starts a Hunchentoot server instance and returns it.
-<code><i>port</i></code> ist the port the server will be listening on
+<blockquote><br> Starts a Hunchentoot server instance named 
+<code><i>name</i></code> and returns it.
+<code><i>port</i></code> is the port the server will be listening on
 - the default is 80 (or 443 if SSL information is provided).
 If <code><i>address</i></code> is a string denoting an IP address,
 then the server only receives connections for that address.  This must
@@ -636,7 +637,7 @@
 <a href="http://www.lispworks.com/documentation/HyperSpec/Body/03_de.htm">destructuring lambda list</a>
 
 <pre>
-  (name &amp;key uri default-parameter-type default-request-type).
+  (name &amp;key uri default-parameter-type default-request-type server-names).
 </pre>
 
 <code><i>lambda-list</i></code> is a list the elements of which are either a symbol
@@ -670,6 +671,9 @@
 <code><i>default-request-type</i></code> (the default of which
 is <code>:BOTH</code>) will be used.
 <p>
+If <code><i>server-names</i></code> is provided, it should be a list of names 
+indicating which servers that this handler will apply. See <a href="#start-server"><code>START-SERVER</code></a>
+<p>
 The value of <code><i>var</i></code> will usually be a string (unless
 it resulted from a <a href="#upload">file upload</a> in which case it won't be converted at
 all), but if <code><i>parameter-type</i></code> (which is evaluated)
Index: easy-handlers.lisp
===================================================================
--- easy-handlers.lisp	(revision 1242)
+++ easy-handlers.lisp	(working copy)
@@ -155,6 +155,24 @@
                                                   ,(or request-type default-request-type)))
                           ,init-form))))
 
+(defun replace-easy-handler-entry (uri name &optional server-names)
+  "Replace an entry in the easy-handler-alist, given an uri and a
+function name. If server-names is not provided, *easy-handler-alist*
+is modified. Otherwise, change the easy-handler-alist slot of the
+named server instances."
+  (macrolet ((do-it (place)
+               `(progn
+                 (setf ,place
+                  (delete-if (lambda (cons)
+                               (or (equal uri (car cons))
+                                   (eq name (cdr cons))))
+                   ,place))
+                 (push (cons uri name) ,place))))
+    (if server-names
+        (dolist (server (mapcar 'make-server server-names))
+          (do-it (server-easy-handler-alist server)))
+        (do-it *easy-handler-alist*))))
+
 (defmacro define-easy-handler (description lambda-list &body body)
   "Defines a handler with the body BODY and optionally registers
 it with a URI so that it will be found by DISPATCH-EASY-HANDLERS.
@@ -188,6 +206,9 @@
 DEFAULT-REQUEST-TYPE \(the default of which is :BOTH) will be
 used.
 
+If server-names is provided, it should be a list of names indicating
+which servers that this handler will apply. See START-SERVER
+
 The value of VAR will usually be a string \(unless it resulted from a
 file upload in which case it won't be converted at all), but if
 PARAMETER-TYPE \(which is evaluated) is provided, the string will be
@@ -273,23 +294,19 @@
     (setq description (list description)))
   (destructuring-bind (name &key uri
                                  (default-parameter-type ''string)
-                                 (default-request-type :both))
-      description
-    (with-unique-names (cons uri%)
+                                 (default-request-type :both)
+                                 server-names)
+      description    
+    (with-unique-names (uri%)
       `(progn
-         ,@(when uri
-             `((let ((,uri% ,uri))
-                 (setq *easy-handler-alist*
-                       (delete-if (lambda (,cons)
-                                    (or (equal ,uri% (car ,cons))
-                                        (eq ',name (cdr ,cons))))
-                                  *easy-handler-alist*))
-                 (push (cons ,uri% ',name) *easy-handler-alist*))))
-         (defun ,name (&key ,@(loop for part in lambda-list
-                                    collect (make-defun-parameter part
-                                                                  default-parameter-type
-                                                                  default-request-type)))
-           , at body)))))
+        (let ((,uri% ,uri))
+          (when ,uri%
+            (replace-easy-handler-entry ,uri% ',name ,server-names)))
+        (defun ,name (&key ,@(loop for part in lambda-list
+                                   collect (make-defun-parameter part
+                                                                 default-parameter-type
+                                                                 default-request-type)))
+          , at body)))))
 
 ;; help the LispWorks IDE to find these definitions
 #+:lispworks
Index: server.lisp
===================================================================
--- server.lisp	(revision 1242)
+++ server.lisp	(working copy)
@@ -30,14 +30,17 @@
 (in-package :hunchentoot)
 
 (defclass server ()
-  ((socket :accessor server-socket
+  ((name :initarg :name :initform nil :accessor server-instance-name
+         :documentation "A name to identify a server
+instance. e.g. :https or :http")
+   (socket :accessor server-socket
            :documentation "The socket the server is listening on.")
    (port :initarg :port
-         :reader server-local-port
+         :accessor server-local-port
          :documentation "The port the server is listening on.
 See START-SERVER.")
    (address :initarg :address
-            :reader server-address
+            :accessor server-address
             :documentation "The address the server is listening
 on.  See START-SERVER.")
    (dispatch-table :initarg :dispatch-table
@@ -45,17 +48,23 @@
                    :documentation "The dispatch-table used by this
 server.  Can be NIL to denote that *META-DISPATCHER* should be called
 instead.")
+   (easy-handler-alist :initarg :easy-handler-alist
+                       :initform nil
+                       :accessor server-easy-handler-alist
+                       :documentation "The easy-handler-alist used by
+this server. Can be NIL to denote that the *easy-handler-alist*
+should be used instead")
    (output-chunking-p :initarg :output-chunking-p
-                      :reader server-output-chunking-p
+                      :accessor server-output-chunking-p
                       :documentation "Whether the server may use output chunking.")
    (input-chunking-p :initarg :input-chunking-p
-                     :reader server-input-chunking-p
+                     :accessor server-input-chunking-p
                      :documentation "Whether the server may use input chunking.")
    (read-timeout :initarg :read-timeout
-                 :reader server-read-timeout
+                 :accessor server-read-timeout
                  :documentation "The read-timeout of the server.")
    (write-timeout :initarg :write-timeout
-                  :reader server-write-timeout
+                  :accessor server-write-timeout
                   :documentation "The write-timeout of the server.")
    (listener :accessor server-listener
              :documentation "The Lisp process which listens for
@@ -66,26 +75,26 @@
             :documentation "A list of currently active worker threads.")
    (mod-lisp-p :initform nil
                :initarg :mod-lisp-p
-               :reader server-mod-lisp-p
+               :accessor server-mod-lisp-p
                :documentation "Whether this is a genuine
 Hunchentoot server or \"just\" infrastructure for mod_lisp.")
    (use-apache-log-p :initarg :use-apache-log-p
-                     :reader server-use-apache-log-p
+                     :accessor server-use-apache-log-p
                      :documentation "Whether the server should use
 Apache's log file.  Only applicable if MOD-LISP-P is true.")
    #-:hunchentoot-no-ssl
    (ssl-certificate-file :initarg :ssl-certificate-file
-                         :reader server-ssl-certificate-file
+                         :accessor server-ssl-certificate-file
                          :documentation "The namestring of a
 certificate file if SSL is used, NIL otherwise.")
    #-:hunchentoot-no-ssl
    (ssl-privatekey-file :initarg :ssl-privatekey-file
-                        :reader server-ssl-privatekey-file
+                        :accessor server-ssl-privatekey-file
                         :documentation "The namestring of a
 private key file if SSL is used, NIL otherwise.")
    #-:hunchentoot-no-ssl
    (ssl-privatekey-password :initarg :ssl-privatekey-password
-                            :reader server-ssl-privatekey-password
+                            :accessor server-ssl-privatekey-password
                             :documentation "The password for the
 private key file or NIL.")
    (lock :initform (make-lock (format nil "hunchentoot-lock-~A"
@@ -96,7 +105,19 @@
   (:documentation "An object of this class contains all relevant
 information about a running Hunchentoot server instance."))
 
-(defun start-server (&key (port 80 port-provided-p)
+(defun make-server (&optional name)
+  "Return a named server if one is already created. Otherwise create a
+new instance and insert it into the named-server alist if name is
+provided."
+  (let ((server (cdr (assoc name *servers* :test #'equalp))))
+    (unless server
+      (setq server (make-instance 'server :name name))
+      (when name
+        (setq *servers* (acons name server *servers*))))
+    (values server)))
+
+(defun initialize-server (&key name
+                          (port 80 port-provided-p)
                           address
                           dispatch-table
                           (mod-lisp-p nil)
@@ -104,11 +125,55 @@
                           (input-chunking-p t)
                           (read-timeout *default-read-timeout*)
                           (write-timeout *default-write-timeout*)
-                          #+(and :unix (not :win32)) setuid
-                          #+(and :unix (not :win32)) setgid
                           #-:hunchentoot-no-ssl ssl-certificate-file
                           #-:hunchentoot-no-ssl (ssl-privatekey-file ssl-certificate-file)
-                          #-:hunchentoot-no-ssl ssl-privatekey-password)
+                          #-:hunchentoot-no-ssl ssl-privatekey-password
+                          &allow-other-keys)
+  "Return a server instance with the various slots initialized properly."
+  (let ((server (make-server name))
+        (output-chunking-p t))
+    #-:hunchentoot-no-ssl
+    (when ssl-certificate-file
+      ;; disable output chunking for SSL connections
+      (setq output-chunking-p nil)
+      (unless port-provided-p (setq port 443)))
+    ;; no timeouts if behind mod_lisp
+    (when mod-lisp-p
+      (setq read-timeout nil
+            write-timeout nil))
+    (setf (server-local-port server) port
+          (server-address server) address
+          (server-dispatch-table server) dispatch-table
+          (server-mod-lisp-p server) mod-lisp-p
+          (server-use-apache-log-p server) (and mod-lisp-p use-apache-log-p)
+          (server-input-chunking-p server) input-chunking-p
+          (server-output-chunking-p server) (and output-chunking-p (not mod-lisp-p))          
+          (server-read-timeout server) read-timeout
+          (server-write-timeout server) write-timeout)
+    #-:hunchentoot-no-ssl
+    (setf (server-ssl-certificate-file server)
+          (and ssl-certificate-file (namestring ssl-certificate-file))
+          (server-ssl-privatekey-file server)
+          (and ssl-privatekey-file (namestring ssl-privatekey-file))
+          (server-ssl-privatekey-password server)
+          ssl-privatekey-password)
+    (values server)))
+
+(defun start-server (&rest args
+                     &key name
+                     (port 80 port-provided-p)
+                     address
+                     dispatch-table
+                     (mod-lisp-p nil)
+                     (use-apache-log-p mod-lisp-p)
+                     (input-chunking-p t)
+                     (read-timeout *default-read-timeout*)
+                     (write-timeout *default-write-timeout*)
+                     #+(and :unix (not :win32)) setuid
+                     #+(and :unix (not :win32)) setgid
+                     #-:hunchentoot-no-ssl ssl-certificate-file
+                     #-:hunchentoot-no-ssl (ssl-privatekey-file ssl-certificate-file)
+                     #-:hunchentoot-no-ssl ssl-privatekey-password)
   "Starts a Hunchentoot server and returns the SERVER object \(which
 can be stopped with STOP-SERVER).  PORT is the port the server will be
 listening on - the default is 80 \(or 443 if SSL information is
@@ -160,104 +225,80 @@
 associated with a password."
   ;; initialize the session secret if needed
   (unless (boundp '*session-secret*)
-    (reset-session-secret))
-  (let ((output-chunking-p t))
-    #-:hunchentoot-no-ssl
-    (when ssl-certificate-file
-      ;; disable output chunking for SSL connections
-      (setq output-chunking-p nil)
-      (unless port-provided-p (setq port 443)))
-    ;; no timeouts if behind mod_lisp
-    (when mod-lisp-p
-      (setq read-timeout nil
-            write-timeout nil))
-    ;; use a new process/lock name for each server
-    (atomic-incf *server-counter*)
-    ;; create the SERVER object
-    (let ((server (make-instance 'server
-                                 :port port
-                                 :address address
-                                 :dispatch-table dispatch-table
-                                 :output-chunking-p (and output-chunking-p (not mod-lisp-p))
-                                 :input-chunking-p input-chunking-p
-                                 #-:hunchentoot-no-ssl #-:hunchentoot-no-ssl
-                                 :ssl-certificate-file (and ssl-certificate-file
-                                                            (namestring ssl-certificate-file))
-                                 #-:hunchentoot-no-ssl #-:hunchentoot-no-ssl
-                                 :ssl-privatekey-file (and ssl-privatekey-file
-                                                           (namestring ssl-privatekey-file))
-                                 #-:hunchentoot-no-ssl #-:hunchentoot-no-ssl
-                                 :ssl-privatekey-password ssl-privatekey-password
-                                 :mod-lisp-p mod-lisp-p
-                                 :use-apache-log-p (and mod-lisp-p use-apache-log-p)
-                                 :read-timeout read-timeout
-                                 :write-timeout write-timeout)))
-      (multiple-value-bind (process condition)
-          ;; start up the actual server
-          (start-up-server :service port
-                           :address address
-                           :process-name (format nil "hunchentoot-listener-~A" *server-counter*)
-                           ;; this function is called once on
-                           ;; startup - we use it to record the
-                           ;; socket
-                           :announce (lambda (socket &optional condition)
-                                       (cond (socket
-                                              (setf (server-socket server) socket))
-                                             (condition
-                                              (error condition))))
-                           ;; this function is called whenever a
-                           ;; connection is made
-                           :function (lambda (handle)
-                                       (with-lock ((server-lock server))
-                                         (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*)))
-                                         ;; start a worker thread
-                                         ;; for this connection
-                                         ;; and remember it
-                                         (push (process-run-function (format nil "hunchentoot-worker-~A"
-                                                                             *worker-counter*)
-                                                                     #'process-connection
-                                                                     server handle)
-                                               (server-workers server))))
-                           ;; wait until the server was
-                           ;; successfully started or an error
-                           ;; condition is returned
-                           :wait t)
-        (cond (process
-               ;; remember the listener so we can kill it later
-               (setf (server-listener server) process))
-              (condition
-               (error condition))))
-      #+(and :unix (not :win32))
-      (when setgid
-        ;; we must make sure to call setgid before we call setuid or
-        ;; suddenly we aren't root anymore...
-        (etypecase setgid
-          (integer (setgid setgid))
-          (string (setgid (get-gid-from-name setgid)))))
-      #+(and :unix (not :win32))
-      (when setuid
-        (etypecase setuid
-          (integer (setuid setuid))
-          (string (setuid (get-uid-from-name setuid)))))
-      server)))
+    (reset-session-secret)) 
+  ;; use a new process/lock name for each server
+  (atomic-incf *server-counter*)
+  ;; create the SERVER object
+  (let ((server (apply #'initialize-server args)))
+    (multiple-value-bind (process condition)
+        ;; start up the actual server
+        (start-up-server :service (server-local-port server)
+                         :address (server-address server)
+                         :process-name (format nil "hunchentoot-listener-~A" *server-counter*)
+                         ;; this function is called once on
+                         ;; startup - we use it to record the
+                         ;; socket
+                         :announce (lambda (socket &optional condition)
+                                     (cond (socket
+                                            (setf (server-socket server) socket))
+                                           (condition
+                                            (error condition))))
+                         ;; this function is called whenever a
+                         ;; connection is made
+                         :function (lambda (handle)
+                                     (with-lock ((server-lock server))
+                                       (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*)))
+                                       ;; start a worker thread
+                                       ;; for this connection
+                                       ;; and remember it
+                                       (push (process-run-function (format nil "hunchentoot-worker-~A"
+                                                                           *worker-counter*)
+                                                                   #'process-connection
+                                                                   server handle)
+                                             (server-workers server))))
+                         ;; wait until the server was
+                         ;; successfully started or an error
+                         ;; condition is returned
+                         :wait t)
+      (cond (process
+             ;; remember the listener so we can kill it later
+             (setf (server-listener server) process))
+            (condition
+             (error condition))))
+    #+(and :unix (not :win32))
+    (when setgid
+      ;; we must make sure to call setgid before we call setuid or
+      ;; suddenly we aren't root anymore...
+      (etypecase setgid
+        (integer (setgid setgid))
+        (string (setgid (get-gid-from-name setgid)))))
+    #+(and :unix (not :win32))
+    (when setuid
+      (etypecase setuid
+        (integer (setuid setuid))
+        (string (setuid (get-uid-from-name setuid)))))
+    server))
 
 (defun stop-server (server)
   "Stops the Hunchentoot server SERVER."
-  ;; use lock so that the listener can't start new workers
-  (with-lock ((server-lock server))
-    ;; kill all worker threads
-    (dolist (worker (server-workers server))
-      (ignore-errors (process-kill worker))
-      (process-allow-scheduling))
-    ;; finally, kill main listener
-    (when-let (listener (server-listener server))
-      (process-kill listener)))
+  (let ((server (if (typep server 'server)
+                    server
+                    (cdr (assoc server *servers* :test #'equalp)))))
+    ;; use lock so that the listener can't start new workers
+    (with-lock ((server-lock server))
+      ;; kill all worker threads
+      (dolist (worker (server-workers server))
+        (ignore-errors (process-kill worker))
+        (process-allow-scheduling))
+      ;; finally, kill main listener
+      (when-let (listener (server-listener server))
+        (process-kill listener))))
   (values))
 
 (defun process-connection (server handle)
@@ -372,6 +413,8 @@
                                            :server-protocol server-protocol))
                  (*dispatch-table* (or (server-dispatch-table *server*)
                                        (funcall *meta-dispatcher* *server*)))
+                 (*easy-handler-alist* (or (server-easy-handler-alist *server*)
+                                           *easy-handler-alist*))
                  backtrace)
             (multiple-value-bind (body error)
                 (catch 'handler-done
Index: specials.lisp
===================================================================
--- specials.lisp	(revision 1242)
+++ specials.lisp	(working copy)
@@ -319,6 +319,9 @@
   "During the execution of dispatchers and handlers this variable
 is bound to the SERVER object which processes the request.")
 
+(defvar *servers* nil
+  "Alist mapping server-name to \(named) server instance.")
+
 (defvar *meta-dispatcher* (lambda (server)
                             (declare (ignore server))
                             *dispatch-table*)
Index: test/test.lisp
===================================================================
--- test/test.lisp	(revision 1242)
+++ test/test.lisp	(working copy)
@@ -471,6 +471,22 @@
                   (loop :for choice :being :the :hash-keys :of meal :collect choice)
                   (gethash "Yellow snow" meal)
                   team)))))
+
+(define-easy-handler (home-page :uri "/hunchentoot/test/easy-home.html"
+                                :server-names '(:http))
+    ()
+  (with-html (:html (:body "Home page"))))
+
+(define-easy-handler (login-page :uri "/hunchentoot/test/easy-login.html"
+                                 :server-names '(:https))
+    ()
+  (with-html (:html (:body "Secure login"))))
+
+(define-easy-handler (common-page :uri "/hunchentoot/test/easy-common.html"
+                                  :server-names '(:https :http))
+    ()
+  (with-html (:html (:body "Common page"))))
+
                 
 
 (defun menu ()
@@ -512,6 +528,12 @@
              " \(same picture)"))
        (:tr (:td (:a :href "/hunchentoot/test/easy-demo.html"
                   "\"Easy\" handler example")))
+       (:tr (:td (:a :href "/hunchentoot/test/easy-home.html"
+                     "\"Easy\" handler example - mockup home page (`http' server instance only)")))
+       (:tr (:td (:a :href "/hunchentoot/test/easy-login.html"
+                     "\"Easy\" handler example - mockup login page (`https' server instance only)")))
+       (:tr (:td (:a :href "/hunchentoot/test/easy-common.html"
+                     "\"Easy\" handler example - mockup common page (http & https)")))
        (:tr (:td (:a :href "/hunchentoot/test/utf8-binary.txt"
                   "UTF-8 demo")
              " \(writing octets directly to the stream)"))
@@ -580,3 +602,12 @@
                  ("/hunchentoot/test/files/" send-file)
                  ("/hunchentoot/test" menu)))
        (list #'default-dispatcher)))
+
+;; (defparameter *server-instance* (start-server :port 8080))
+;; (stop-server *server-instance*)
+
+;; (start-server :name :http :port 8000)
+;; (stop-server :http)
+
+;; (start-server :name :https :port 4443)
+;; (stop-server :https)

From rm at seid-online.de  Sat May 19 15:29:48 2007
From: rm at seid-online.de (Ralf Mattes)
Date: Sat, 19 May 2007 17:29:48 +0200
Subject: [hunchentoot-devel] Bugreport (and patch)
Message-ID: <1179588588.6432.4.camel@localhost.localdomain>

Hello,

during some moderate WebDAV conformance tests is stumbled over the
following bug/typo:

--- handlers.lisp       2007-04-18 02:29:07.000000000 +0200
+++ /LISP/ediware/cl-webdav/handlers.lisp       2007-05-19
17:05:45.000000000 +0200
@@ -314,7 +314,7 @@
   (let ((resource (get-resource)))
     (when (resource-exists resource)
       (setf (header-out :allow)
-            (format nil "~{~A~^~, ~}"
+            (format nil "~{~A~^, ~}"
                     (set-difference *allowed-methods*
'(:get :head :mkcol))))
       (method-not-allowed))
     (let ((parent (resource-parent resource)))


MKCOL on an existing resource created an 500 status instead of the
expected 405.


 Cheers, RalfD



From edi at agharta.de  Sat May 19 22:37:35 2007
From: edi at agharta.de (Edi Weitz)
Date: Sun, 20 May 2007 00:37:35 +0200
Subject: [hunchentoot-devel] New CL-WEBDAV release 0.1.1 (Was: Bugreport
	(and patch))
In-Reply-To: <1179588588.6432.4.camel@localhost.localdomain> (Ralf Mattes's
	message of "Sat, 19 May 2007 17:29:48 +0200")
References: <1179588588.6432.4.camel@localhost.localdomain>
Message-ID: <ulkfk5tjk.fsf@agharta.de>

On Sat, 19 May 2007 17:29:48 +0200, Ralf Mattes <rm at seid-online.de> wrote:

> during some moderate WebDAV conformance tests is stumbled over the
> following bug/typo:
>
> --- handlers.lisp       2007-04-18 02:29:07.000000000 +0200
> +++ /LISP/ediware/cl-webdav/handlers.lisp       2007-05-19
> 17:05:45.000000000 +0200
> @@ -314,7 +314,7 @@
>    (let ((resource (get-resource)))
>      (when (resource-exists resource)
>        (setf (header-out :allow)
> -            (format nil "~{~A~^~, ~}"
> +            (format nil "~{~A~^, ~}"
>                      (set-difference *allowed-methods*
> '(:get :head :mkcol))))
>        (method-not-allowed))
>      (let ((parent (resource-parent resource)))
>
> MKCOL on an existing resource created an 500 status instead of the
> expected 405.

Ah, right, thanks.  Fixed in 0.1.1.

Good to know that someone is finally testing this... :)

Cheers,
Edi.


From ocorrain at gmail.com  Sun May 20 11:32:53 2007
From: ocorrain at gmail.com (Tiarnan O'Corrain)
Date: Sun, 20 May 2007 12:32:53 +0100
Subject: [hunchentoot-devel] Hunchentoot not working on OpenMCL 1.1pre
Message-ID: <ea7fafc0705200432t6d0a7572v41ce2782ae46fa9d@mail.gmail.com>

Hi--

I've just installed a brand new OpenMCL pre-prelease ("Version
1.1-pre-070512 (DarwinPPC32)") and am getting the following error in
the browser when accessing the default hunchentoot page:

NIL
Unknown http return code: 200

A backtrace from SLIME is given below.  Originally I thought the
problem was due to a reference in port-mcl.lisp to
ccl::make-timer-request:  I installed acl-compat, which provides this,
with no change in outcome.

Any pointers to fruitful areas of investigation would be appreciated.

regards

Tiarn?n


Stream #<BASIC-FILE-BINARY-OUTPUT-STREAM ("/tmp/hunchentoot.log"/24
ISO-8859-1) #x93BC97E> is private to #<PROCESS
hunchentoot-worker-1(48) [Exhausted] #x93BBC1E>
   [Condition of type SIMPLE-ERROR]

Restarts:
 0: [ABORT-BREAK] Reset this process
 1: [ABORT] Kill this process

Backtrace:
  0: (#<Anonymous Function #x85C7C2E> 0 20)
  1: (SWANK:BACKTRACE 1 41)
  2: (CCL::CALL-CHECK-REGS 'SWANK:BACKTRACE)
  3: (#<Anonymous Function #x86434AE> '(SWANK:BACKTRACE 1 41) 44 'NIL)
  4: (#<Anonymous Function #x85687F6> #<Compiled-function
SWANK:SWANK-DEBUGGER-HOOK #x863C6A6> #<COMPILED-LEXICAL-CLOSURE
#x93EE3CE>)
  5: (FUNCALL 'SWANK::EVAL-FOR-EMACS)
  6: (SWANK::SLDB-LOOP '(70 T 10 T NIL 10 T
       #S(CCL::PPRINT-DISPATCH-TABLE :CONSES-WITH-CARS #<HASH-TABLE
:TEST EQ size 60/60 #x85DEBB6>
                                     :STRUCTURES NIL
                                     :OTHERS (#<CCL::ENTRY #x846914E> #))
       NIL T ...))
  7: (SWANK::CALL-WITH-BINDINGS '((*PRINT-PRETTY* . T) (*PRINT-LEVEL*
. 4) (*PRINT-LENGTH* . 10)
       (*PRINT-CIRCLE* . T) (*PRINT-READABLY*)
       (*PRINT-PPRINT-DISPATCH*
        . #S(CCL::PPRINT-DISPATCH-TABLE :CONSES-WITH-CARS #<HASH-TABLE
:TEST EQ size 60/60 #x85DEBB6>
                                        :STRUCTURES NIL
                                        :OTHERS (# #)))
       (*PRINT-GENSYM* . T) (*PRINT-BASE* . 10) (*PRINT-RADIX*)
       (*PRINT-ARRAY* . T) ...) #<Anonymous Function #x863B636>)
  8: (#<Anonymous Function #x85C8B56> #<Anonymous Function #x863B686>)
  9: (SWANK::DEBUG-IN-EMACS #<SIMPLE-ERROR #x93DEBA6>)
 10: (#<Anonymous Function #x85687F6> #<Compiled-function
SWANK:SWANK-DEBUGGER-HOOK #x863C6A6> #<COMPILED-LEXICAL-CLOSURE
#x93DEB56>)
 11: (SWANK::CALL-WITH-REDIRECTED-IO #<COMPILED-LEXICAL-CLOSURE
#x93DEB3E> #<Compiled-function SWANK:SWANK-DEBUGGER-HOOK #x863C6A6>)
 12: (SWANK::CALL-WITH-CONNECTION #<CONNECTION  #x869E2CE>
#<COMPILED-LEXICAL-CLOSURE #x93DEB56>)
 13: (INVOKE-DEBUGGER #<SIMPLE-ERROR #x93DEBA6>)
 14: (SIGNAL #<SIMPLE-ERROR #x93DEBA6>)
 15: (CCL::%ERROR '(#<BASIC-FILE-BINARY-OUTPUT-STREAM
("/tmp/hunchentoot.log"/24 ISO-8859-1) #x93BC97E>
       #<PROCESS hunchentoot-worker-1(48) [Exhausted] #x93BBC1E>) -65534292)
 16: (CCL::%PRIVATE-IOBLOCK-WRITE-U8-BYTE 91
#<BASIC-FILE-BINARY-OUTPUT-STREAM ("/tmp/hunchentoot.log"/24
ISO-8859-1) #x93BC97E>)
 17: (WRITE-BYTE 91 'FLEXI-STREAMS::WRITE-BYTE*)
      Locals:
        CCL::IOBLOCK = #S(CCL::FILE-IOBLOCK :STREAM
#<BASIC-FILE-BINARY-OUTPUT-STREAM ("/tmp/hunchentoot.log"/24
ISO-8859-1) #x93BC97E>
		                            :UNTYI-CHAR NIL :INBUF NIL
		                            :OUTBUF #<IO-BUFFER  (UNSIGNED-BYTE
		                                                  8) 0/0/2048 #x93BC86E>
		                            :ELEMENT-TYPE ...)
 18: (#<STANDARD-METHOD STREAM-WRITE-CHAR
(FLEXI-STREAMS::FLEXI-UTF-8-OUTPUT-STREAM
                                          T)> #\[ '(NIL
       #<STANDARD-METHOD STREAM-WRITE-CHAR
(FLEXI-STREAMS::FLEXI-UTF-8-OUTPUT-STREAM
                                            T)>
       . 8955664))
 19: (CCL::%%BEFORE-AND-AFTER-COMBINED-METHOD-DCODE '(NIL
       #<STANDARD-METHOD STREAM-WRITE-CHAR
(FLEXI-STREAMS::FLEXI-UTF-8-OUTPUT-STREAM
                                            T)>
       . 8955664))
 20: (CCL::%%STANDARD-COMBINED-METHOD-DCODE 0 #\[)
 21: (#<STANDARD-METHOD TRIVIAL-GRAY-STREAMS:STREAM-WRITE-SEQUENCE
(FLEXI-STREAMS:FLEXI-OUTPUT-STREAM
                                                                   T
                                                                   T
                                                                   T)>
#<FLEXI-STREAMS::FLEXI-UTF-8-OUTPUT-STREAM #x93BC72E> "[~A~@[ [~A]~]]
~A~%" 0 1)
 22: (WRITE-STRING "[~A~@[ [~A]~]] ~A~%"
#<FLEXI-STREAMS::FLEXI-UTF-8-OUTPUT-STREAM #x93BC72E>)
      Locals:
        OUTPUT-STREAM = #<FLEXI-STREAMS::FLEXI-UTF-8-OUTPUT-STREAM #x93BC72E>
        CCL::START = 0
        CCL::END = 1
 23: (CCL::SUB-FORMAT #<FLEXI-STREAMS::FLEXI-UTF-8-OUTPUT-STREAM
#x93BC72E> 0 19)
 24: (CCL::DO-SUB-FORMAT #<FLEXI-STREAMS::FLEXI-UTF-8-OUTPUT-STREAM #x93BC72E>)
 25: (FORMAT #<FLEXI-STREAMS::FLEXI-UTF-8-OUTPUT-STREAM #x93BC72E>
"[~A~@[ [~A]~]] ~A~%")
 26: (#<STANDARD-METHOD HUNCHENTOOT:LOG-MESSAGE (T T)> ':INFO "Default
handler called for script ~A")
      Locals:
        HUNCHENTOOT::LOG-LEVEL = :INFO
        HUNCHENTOOT::FMT = "Default handler called for script ~A"
        HUNCHENTOOT::ARGS = ("/hunchentoot/")
        HUNCHENTOOT::MESSAGE = "Default handler called for script /hunchentoot/"
        CCL::*INTERRUPT-LEVEL* = 0
        CCL::*INTERRUPT-LEVEL* = -1
        CCL::%HANDLERS% = ((ERROR #1=#<STANDARD-GENERIC-FUNCTION
HUNCHENTOOT:MAYBE-INVOKE-DEBUGGER #x8A9D2B6>)
			   (ERROR #<COMPILED-LEXICAL-CLOSURE #x93DED06>
			          WARNING
			          #<COMPILED-LEXICAL-CLOSURE #x93DECEE>)
			   (ERROR #1#)
			   (ERROR #<COMPILED-LEXICAL-CLOSURE #x93E156E>
			          WARNING
			          #<Anonymous Function #x8F56EC6>)
			   (PROCESS-RESET))
        #:G3734 = (ERROR #<STANDARD-GENERIC-FUNCTION
HUNCHENTOOT:MAYBE-INVOKE-DEBUGGER #x8A9D2B6>)
        CCL::%HANDLERS% = ((ERROR)
			   (ERROR #1=#<STANDARD-GENERIC-FUNCTION
HUNCHENTOOT:MAYBE-INVOKE-DEBUGGER #x8A9D2B6>)
			   (ERROR #<COMPILED-LEXICAL-CLOSURE #x93DED06>
			          WARNING
			          #<COMPILED-LEXICAL-CLOSURE #x93DECEE>)
			   (ERROR #1#)
			   (ERROR #<COMPILED-LEXICAL-CLOSURE #x93E156E>
			          WARNING
			          #<Anonymous Function #x8F56EC6>)
			   (PROCESS-RESET))
        CCL::%HANDLERS% = ((ERROR #1=#<STANDARD-GENERIC-FUNCTION
HUNCHENTOOT:MAYBE-INVOKE-DEBUGGER #x8A9D2B6>)
			   (ERROR) (ERROR #1#)
			   (ERROR #<COMPILED-LEXICAL-CLOSURE #x93DED06>
			          WARNING
			          #<COMPILED-LEXICAL-CLOSURE #x93DECEE>)
			   (ERROR #1#)
			   (ERROR #<COMPILED-LEXICAL-CLOSURE #x93E156E>
			          WARNING
			          #<Anonymous Function #x8F56EC6>)
			   (PROCESS-RESET))
        CCL::%HANDLERS% = ((ERROR)
			   (ERROR #1=#<STANDARD-GENERIC-FUNCTION
HUNCHENTOOT:MAYBE-INVOKE-DEBUGGER #x8A9D2B6>)
			   (ERROR) (ERROR #1#)
			   (ERROR #<COMPILED-LEXICAL-CLOSURE #x93DED06>
			          WARNING
			          #<COMPILED-LEXICAL-CLOSURE #x93DECEE>)
			   (ERROR #1#)
			   (ERROR #<COMPILED-LEXICAL-CLOSURE #x93E156E>
			          WARNING
			          #<Anonymous Function #x8F56EC6>) ..)
      Catch-tags:
        NIL
        NIL
        NIL
 27: (HUNCHENTOOT::DEFAULT-HANDLER)
      [No Locals]
 28: (HUNCHENTOOT::PROCESS-REQUEST '((:HOST . "localhost:4242")
       (:USER-AGENT
        . "Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US;
rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3")
       (:ACCEPT
        . "text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5")
       (:ACCEPT-LANGUAGE . "en-us,en;q=0.5")
       (:ACCEPT-ENCODING . "gzip,deflate")
       (:ACCEPT-CHARSET . "ISO-8859-1,utf-8;q=0.7,*;q=0.7")
       (:KEEP-ALIVE . "300") (:CONNECTION . "keep-alive")
       (:CACHE-CONTROL . "max-age=0"))
#<FLEXI-STREAMS::FLEXI-LATIN-1-IO-STREAM #x93DF4B6> ':GET
"/hunchentoot/" ':HTTP/1.1)
      Locals:
        HUNCHENTOOT:HEADERS-IN = ((:HOST . "localhost:4242")
				  (:USER-AGENT
				   . "Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US;
rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3")
				  (:ACCEPT
				   . "text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5")
				  (:ACCEPT-LANGUAGE . "en-us,en;q=0.5")
				  (:ACCEPT-ENCODING . "gzip,deflate")
				  (:ACCEPT-CHARSET . "ISO-8859-1,utf-8;q=0.7,*;q=0.7")
				  (:KEEP-ALIVE . "300") (:CONNECTION . "keep-alive")
				  (:CACHE-CONTROL . "max-age=0"))
        HUNCHENTOOT::CONTENT-STREAM =
#<FLEXI-STREAMS::FLEXI-LATIN-1-IO-STREAM #x93DF4B6>
        METHOD = :GET
        HUNCHENTOOT::URL-STRING = "/hunchentoot/"
        HUNCHENTOOT:SERVER-PROTOCOL = :HTTP/1.1
        HUNCHENTOOT::*TMP-FILES* = NIL
        HUNCHENTOOT::*HEADERS-SENT* = NIL
        CCL::*INTERRUPT-LEVEL* = 0
        CCL::*INTERRUPT-LEVEL* = -1
        HUNCHENTOOT:*SESSION* = #<Unbound>
        HUNCHENTOOT:*REPLY* = #<Unbound>
        HUNCHENTOOT:*REQUEST* = #<Unbound>
        HUNCHENTOOT:*DISPATCH-TABLE* = (HUNCHENTOOT:DEFAULT-DISPATCHER)
        HUNCHENTOOT::BACKTRACE = #<VALUE-CELL NIL #x93DED1E>
        CCL::%HANDLERS% = ((ERROR #<STANDARD-GENERIC-FUNCTION
HUNCHENTOOT:MAYBE-INVOKE-DEBUGGER #x8A9D2B6>)
			   (ERROR #<COMPILED-LEXICAL-CLOSURE #x93E156E>
			          WARNING
			          #<Anonymous Function #x8F56EC6>)
			   (PROCESS-RESET))
        CCL::%HANDLERS% = ((ERROR #<COMPILED-LEXICAL-CLOSURE #x93DED06>
			          WARNING
			          #<COMPILED-LEXICAL-CLOSURE #x93DECEE>)
			   (ERROR #<STANDARD-GENERIC-FUNCTION
HUNCHENTOOT:MAYBE-INVOKE-DEBUGGER #x8A9D2B6>)
			   (ERROR #<COMPILED-LEXICAL-CLOSURE #x93E156E>
			          WARNING
			          #<Anonymous Function #x8F56EC6>)
			   (PROCESS-RESET))
      Catch-tags:
        HUNCHENTOOT:HANDLER-DONE
        NIL
 29: (HUNCHENTOOT::PROCESS-CONNECTION #<HUNCHENTOOT::SERVER #x93BBAC6>
#<BASIC-TCP-STREAM ISO-8859-1 (SOCKET/23) #x93DC88E>)
      Locals:
        HUNCHENTOOT::SERVER = #<HUNCHENTOOT::SERVER #x93BBAC6>
        HUNCHENTOOT::HANDLE = #<BASIC-TCP-STREAM ISO-8859-1
(SOCKET/23) #x93DC88E>
        #:COMPILER-VAR = (NIL)
        #:G4134 = (ERROR #<COMPILED-LEXICAL-CLOSURE #x93E156E>
		         WARNING
		         #<Anonymous Function #x8F56EC6>)
        CCL::%HANDLERS% = ((PROCESS-RESET))
        #:G4135 = (ERROR #<STANDARD-GENERIC-FUNCTION
HUNCHENTOOT:MAYBE-INVOKE-DEBUGGER #x8A9D2B6>)
        CCL::%HANDLERS% = ((ERROR #<COMPILED-LEXICAL-CLOSURE #x93E156E>
			          WARNING
			          #<Anonymous Function #x8F56EC6>)
			   (PROCESS-RESET))
        HUNCHENTOOT::*HUNCHENTOOT-STREAM* = #<Unbound>
        HUNCHENTOOT::*LOCAL-HOST* = #<Unbound>
        HUNCHENTOOT::*REMOTE-HOST* = #<Unbound>
        HUNCHENTOOT::*REMOTE-PORT* = #<Unbound>
        CCL::*INTERRUPT-LEVEL* = 0
        CCL::*INTERRUPT-LEVEL* = -1
        HUNCHENTOOT:*SERVER* = #<Unbound>
        CCL::*INTERRUPT-LEVEL* = 0
        CCL::*INTERRUPT-LEVEL* = -1
        HUNCHENTOOT::*CLOSE-HUNCHENTOOT-STREAM* = NIL
        HUNCHENTOOT:HEADERS-IN = ((:HOST . "localhost:4242")
				  (:USER-AGENT
				   . "Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US;
rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3")
				  (:ACCEPT
				   . "text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5")
				  (:ACCEPT-LANGUAGE . "en-us,en;q=0.5")
				  (:ACCEPT-ENCODING . "gzip,deflate")
				  (:ACCEPT-CHARSET . "ISO-8859-1,utf-8;q=0.7,*;q=0.7")
				  (:KEEP-ALIVE . "300") (:CONNECTION . "keep-alive")
				  (:CACHE-CONTROL . "max-age=0"))
        HUNCHENTOOT::CONTENT-STREAM =
#<FLEXI-STREAMS::FLEXI-LATIN-1-IO-STREAM #x93DF4B6>
        METHOD = :GET
        HUNCHENTOOT::URL-STRING = "/hunchentoot/"
        HUNCHENTOOT:SERVER-PROTOCOL = :HTTP/1.1
      Catch-tags:
        NIL
        NIL
        NIL
 30: (CCL::RUN-PROCESS-INITIAL-FORM '(#<COMPILED-LEXICAL-CLOSURE
#x93DC32E>) #<PROCESS hunchentoot-worker-2(49) [Active] #x93DC366>)
 31: (#<Anonymous Function #x8174C16> '(#<COMPILED-LEXICAL-CLOSURE
#x93DC32E>) 0)
 32: (#<Anonymous Function #x815EF56> 790464 #<LISP-THREAD
hunchentoot-worker-2 [tcr @ #x303F00] #x93DC4DE>)


From lispercat at gmail.com  Sun May 20 17:59:06 2007
From: lispercat at gmail.com (Andrei Stebakov)
Date: Sun, 20 May 2007 13:59:06 -0400
Subject: [hunchentoot-devel] Logging with cronolog (hunchentoot behind
	mod_proxy)
Message-ID: <affe56e00705201059o35a7c9e8qbb226ee536094f31@mail.gmail.com>

I am wondering if anyone is using cronolog with hunchentoot to split logging
by year, month and day?
I am using hunchentoot behind mod_proxy so can I rely on Apache's settings
like CustomLog "|/usr/bin/cronolog /WebLogs/%Y/%m/%d-access.log".?
I am just looking for some ideas how you split the log.

Thank you,
Andrew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20070520/b965f1c9/attachment.html>

From rm at seid-online.de  Sun May 20 17:59:37 2007
From: rm at seid-online.de (Ralf Mattes)
Date: Sun, 20 May 2007 19:59:37 +0200
Subject: [hunchentoot-devel] Re: New CL-WEBDAV release 0.1.1 (Was: Bugreport
	(and patch))
In-Reply-To: <ulkfk5tjk.fsf@agharta.de>
References: <1179588588.6432.4.camel@localhost.localdomain>
	<ulkfk5tjk.fsf@agharta.de>
Message-ID: <1179683977.6399.6.camel@localhost.localdomain>

On Sun, 2007-05-20 at 00:37 +0200, Edi Weitz wrote:
> On Sat, 19 May 2007 17:29:48 +0200, Ralf Mattes <rm at seid-online.de> wrote:
> 
> > during some moderate WebDAV conformance tests is stumbled over the
> > following bug/typo:
> >
> > --- handlers.lisp       2007-04-18 02:29:07.000000000 +0200
> > +++ /LISP/ediware/cl-webdav/handlers.lisp       2007-05-19
> > 17:05:45.000000000 +0200
> > @@ -314,7 +314,7 @@
> >    (let ((resource (get-resource)))
> >      (when (resource-exists resource)
> >        (setf (header-out :allow)
> > -            (format nil "~{~A~^~, ~}"
> > +            (format nil "~{~A~^, ~}"
> >                      (set-difference *allowed-methods*
> > '(:get :head :mkcol))))
> >        (method-not-allowed))
> >      (let ((parent (resource-parent resource)))
> >
> > MKCOL on an existing resource created an 500 status instead of the
> > expected 405.
> 
> Ah, right, thanks.  Fixed in 0.1.1.

Thank's - but i think there's more to come. I'll collect the patches
until later since you don't use a public VC and i hate to have to merge
my versions into your new releases ... ;-)
 
> 
> Good to know that someone is finally testing this... :)

Oh - i guess i'm deep into 'Uebersprunghandlung'-Mode ...

 Cheers, RalfD
  
> Cheers,
> Edi.

P.S.: I'm giong to be in Hamburg Tue./Wed. - care for some beverage?  



From edi at agharta.de  Sun May 20 18:46:59 2007
From: edi at agharta.de (Edi Weitz)
Date: Sun, 20 May 2007 20:46:59 +0200
Subject: [hunchentoot-devel] Re: New CL-WEBDAV release 0.1.1
In-Reply-To: <1179683977.6399.6.camel@localhost.localdomain> (Ralf Mattes's
	message of "Sun, 20 May 2007 19:59:37 +0200")
References: <1179588588.6432.4.camel@localhost.localdomain>
	<ulkfk5tjk.fsf@agharta.de>
	<1179683977.6399.6.camel@localhost.localdomain>
Message-ID: <uveen49jw.fsf@agharta.de>

On Sun, 20 May 2007 19:59:37 +0200, Ralf Mattes <rm at seid-online.de> wrote:

> Thank's - but i think there's more to come.

Good, looking forward to that.

> I'll collect the patches until later since you don't use a public VC
> and i hate to have to merge my versions into your new releases
> ... ;-)

You're just lazy.  And for the same reason I don't use a public VC
system... :)

> Oh - i guess i'm deep into 'Uebersprunghandlung'-Mode ...

Hehe.

> P.S.: I'm giong to be in Hamburg Tue./Wed. - care for some beverage?  

Yep.  I'll email you privately.

Cheers,
Edi.


From syamajala at gamebox.net  Wed May 23 00:33:05 2007
From: syamajala at gamebox.net (syamajala at gamebox.net)
Date: Tue, 22 May 2007 20:33:05 -0400
Subject: [hunchentoot-devel] problem on macosx with openmcl
Message-ID: <1FCCF299-C122-41D0-8B63-5C04E6186587@gamebox.net>

Hello, I have been trying to get hunchentoot to work on mac os x with  
openmcl. It seems to load correctly and everything, but when I  
compile my program and try to access the page i get an error that  
says: Unknown http return code: 500

- Seshu 


From emailmac at gmail.com  Wed May 23 01:10:35 2007
From: emailmac at gmail.com (Mac Chan)
Date: Tue, 22 May 2007 18:10:35 -0700
Subject: [hunchentoot-devel] Lisp server page for hunchentoot
Message-ID: <4877ae640705221810y6773ad26m37ccff9b647b0578@mail.gmail.com>

I ported John Wiseman's lsp for use by hunchentoot.

You can check out the source from the contrib directory :

svn checkout svn://common-lisp.net/project/tbnl/svn

http://common-lisp.net/websvn/listing.php?repname=tbnl&path=%2Fcontrib%2Flsp%2F

Comments welcomed.

Cheers,
-- Mac


The following are copied verbatim from the comment

(asdf:oos 'asdf:load-op :cl-ppcre)
(asdf:oos 'asdf:load-op :hunchentoot-test)
(hunchentoot:start-server :port 8080)

;; verify that hunchentoot is running
;; http://localhost:8080/hunchentoot/test/

(asdf:oos 'asdf:load-op :lsp)

(in-package :lsp)

;; set debug on so we can examine the generated code
(set-lsp-debug t)

;; use cl-user package for all unqualified symbols
(set-lsp-package :cl-user)

;; compile the test file
(get-lsp-function (merge-pathnames "test.lsp" *this-dir*))

;; take a look at the generated code
(show-lsp-form (merge-pathnames "test.lsp" *this-dir*))

;; print the output to REPL
(do-lsp-request (merge-pathnames "test.lsp" *this-dir*))

;; install the dispatcher function
(push
  (create-lsp-folder-dispatcher-and-handler
  ;; uri
  "/hunchentoot/lsp/"
  ;; directory
  *this-dir*
  ;; valid lsp page suffixes
  '("lsp" "lhtml" "lhtm" "asp")
  ;; default content-type for non lsp files
  "text/plain")
  hunchentoot:*dispatch-table*)

;; try it out (click refresh a few times to verify that it is _dynamic_)
;; http://localhost:8080/hunchentoot/lsp/test.lsp

;; take a look at the source code too
;; http://localhost:8080/hunchentoot/lsp/lsp.lisp


;; alternatively, you can also create separate handler for each lsp file
(push
  (hunchentoot:create-prefix-dispatcher
  "/hunchentoot/lsp/test.lsp"
  (get-lsp-function (merge-pathnames "test.lsp" *this-dir*)))
  hunchentoot:*dispatch-table*)

;; finally, you can also reuse lsp function within a custom dispatch handler
(hunchentoot:define-easy-handler (lsp-demo :uri
"/hunchentoot/test/lsp-demo.html")
    ()
  (do-lsp-request (merge-pathnames "test.lsp" *this-dir*)))

;; http://localhost:8080/hunchentoot/test/lsp-demo.html


LAQ:

* Why another template module?

There are indeed a lot of template libraries including CL-EMB, Edi's
own HTML-TEMPLATE, etc. But these libraries are obstinate in that they
require you to construct and pass the `environment' variable in order
to generate the dynamic content.

Secondly, I found that the @if @else template extensions/add-ons are
often too limited in expressive power. You are programming lisp in the
backend, but all of a sudden you need to drop to a very dumb language
when you need to deal with the template code, which is kind of
frustrating.

John Wiseman's code is very close to what I need, but it is designed
to work with Franz's allegoserver. So I port it to work with my
preferred web server (hunchentoot) instead.


* So should I use this for all my dynamic content generation?

No. Absolutely not. If you take a look at the very simple test.lsp, it
screams like spaghetti code!

In the ideal world, if the graphics designer can deliver properly
formatted html in cl-who sexp, I'm all set. But that's not gonna
happen.

So for pages that I have total control, I prefer to write it using
sexp. However, there are times where the designer need to frequently
update a messy html template and I cannot afford to sync up with it
given the time constraint, using lsp is a good compromise.


* Any tips & tricks?

Lisp is very hard to write (and even harder to read) without a good
editor (like emacs) to help indenting your code and provide structured
editing.

So unlike other dumber languages (php, perl...), intermixed lisp code
with content is extremely hard to maintain and read.

In this regard, I would recommend you to use Franz's if-star package
( http://www.franz.com/~jkf/ifstar.txt ) in your template file because
it helps you to match the open and close parenthesis for if-then-else
conditional expression.

Also, unlike other dumber languages where if you have a syntax error
in the template file, the compiler can point you to the exact line
where it occurs. With lsp, the line number is lost when we use the
built-in lisp reader to read the form. However you can use
`show-lsp-form' in the REPL to examine the code when you encounter an
error.


From edi at agharta.de  Wed May 23 08:04:44 2007
From: edi at agharta.de (Edi Weitz)
Date: Wed, 23 May 2007 10:04:44 +0200
Subject: [hunchentoot-devel] problem on macosx with openmcl
In-Reply-To: <1FCCF299-C122-41D0-8B63-5C04E6186587@gamebox.net>
	(syamajala@gamebox.net's
	message of "Tue, 22 May 2007 20:33:05 -0400")
References: <1FCCF299-C122-41D0-8B63-5C04E6186587@gamebox.net>
Message-ID: <uirakufs3.fsf@agharta.de>

On Tue, 22 May 2007 20:33:05 -0400, "syamajala at gamebox.net" <syamajala at gamebox.net> wrote:

> Hello, I have been trying to get hunchentoot to work on mac os x
> with openmcl. It seems to load correctly and everything, but when I
> compile my program and try to access the page i get an error that
> says: Unknown http return code: 500

This is a known problem (see the archives of this mailing list and of
the FLEXI-STREAMS mailing list) which I can't fix ATM because I don't
have a Mac.


From edi at agharta.de  Wed May 23 08:15:18 2007
From: edi at agharta.de (Edi Weitz)
Date: Wed, 23 May 2007 10:15:18 +0200
Subject: [hunchentoot-devel] Lisp server page for hunchentoot
In-Reply-To: <4877ae640705221810y6773ad26m37ccff9b647b0578@mail.gmail.com> (Mac
	Chan's message of "Tue, 22 May 2007 18:10:35 -0700")
References: <4877ae640705221810y6773ad26m37ccff9b647b0578@mail.gmail.com>
Message-ID: <uejl8ufah.fsf@agharta.de>

On Tue, 22 May 2007 18:10:35 -0700, "Mac Chan" <emailmac at gmail.com> wrote:

> I ported John Wiseman's lsp for use by hunchentoot.

Nice.  I've added a link to the Hunchentoot website.


From edi at agharta.de  Wed May 23 09:49:16 2007
From: edi at agharta.de (Edi Weitz)
Date: Wed, 23 May 2007 11:49:16 +0200
Subject: [hunchentoot-devel] Re: [flexi-streams-devel] Flexi-streams test
 suite failing on OpenMCL
In-Reply-To: <ea7fafc0705211332o29e3be01t8fd14ca8922e5c43@mail.gmail.com>
	(Tiarnan O'Corrain's message of "Mon, 21 May 2007 21:32:45 +0100")
References: <ea7fafc0705211332o29e3be01t8fd14ca8922e5c43@mail.gmail.com>
Message-ID: <uk5uzeuoz.fsf@agharta.de>

On Mon, 21 May 2007 21:32:45 +0100, "Tiarnan O'Corrain" <ocorrain at gmail.com> wrote:

> The flexi-streams test suite is failing on OpenMCL "Version 1.0
> (DarwinPPC32)" on
>
> Test "hebrew_utf8_lf.txt" (:UTF-8 :EOL-STYLE :LF) [INPUT]
>  --> (:UTF-8 :EOL-STYLE :LF) [OUTPUT].

FWIW, I just borrowed my wife's iBook (PPC, OS X 10.3) for a couple of
minutes and tried with OpenMCL Version 1.1 Prerelease 070512 (PPC-32).
The test suite ran without problems for me.  Could you check if it
works for you as well?

> I think this is also preventing Hunchentoot from working on recent
> OpenMCL versions

In the meantime, I've come to think this is another issue.  I also had
the problems others reported and the error message was something about
some stream being "private" to some process.  But I don't have enough
time to dig into this, so if nobody steps up to resolve the issues
with OpenMCL, I'll remove OpenMCL support from Hunchentoot for now.


From ocorrain at gmail.com  Wed May 23 10:12:36 2007
From: ocorrain at gmail.com (Tiarnan O'Corrain)
Date: Wed, 23 May 2007 11:12:36 +0100
Subject: [hunchentoot-devel] Re: [flexi-streams-devel] Flexi-streams test
	suite failing on OpenMCL
In-Reply-To: <uk5uzeuoz.fsf@agharta.de>
References: <ea7fafc0705211332o29e3be01t8fd14ca8922e5c43@mail.gmail.com>
	<uk5uzeuoz.fsf@agharta.de>
Message-ID: <ea7fafc0705230312w58c29d67p121c869c8c52028@mail.gmail.com>

Hi Edi--

> I don't have enough
> time to dig into this, so if nobody steps up to resolve the issues
>with OpenMCL, I'll remove OpenMCL support from Hunchentoot for now.

The nuclear option?  I recall hunchentoot working on OpenMCL a few months
ago -- I was using it for some development (deployment to be on FreeBSD/cmucl),
without any problems.  Then the Mac got sick for a while, and when I
got it back,
hunchentoot was broken.

The unfortunate upshot of this (for me, at least), is that hunchentoot
will no longer
be deployable on a free Mac lisp, as SBCL/Mac doesn't have threading, and
CMUCL/Mac is missing the multiprocessing package.

I'll try it out on the version you suggested later on today -- I'm
using Mac OS X
10.4, so perhaps that has something to do with it.  Another possibility would be
to ask Gary Byers on the OpenMCL mailing list -- I'll do that when I
get a chance
to look at the problem in more detail.

Thanks,

Tiarn?n


From rm at seid-online.de  Wed May 23 13:46:58 2007
From: rm at seid-online.de (Ralf Mattes)
Date: Wed, 23 May 2007 15:46:58 +0200
Subject: [hunchentoot-devel] (Non)-Bug in subclassing dav:file-resource
Message-ID: <1179928018.6446.2.camel@localhost.localdomain>

Ok,  I looked closer at the code for authorized-file-resource  - I
forgot to implement accept-request-p ... after fixing this everything
works fine now.

 Thanks, RalfD



From ocorrain at gmail.com  Wed May 23 13:51:43 2007
From: ocorrain at gmail.com (Tiarnan O'Corrain)
Date: Wed, 23 May 2007 14:51:43 +0100
Subject: [hunchentoot-devel] Re: [flexi-streams-devel] Flexi-streams test
	suite failing on OpenMCL
In-Reply-To: <ea7fafc0705230312w58c29d67p121c869c8c52028@mail.gmail.com>
References: <ea7fafc0705211332o29e3be01t8fd14ca8922e5c43@mail.gmail.com>
	<uk5uzeuoz.fsf@agharta.de>
	<ea7fafc0705230312w58c29d67p121c869c8c52028@mail.gmail.com>
Message-ID: <ea7fafc0705230651l40e4f58j8c0f7e9c4c5a87bd@mail.gmail.com>

Hi Edi--

any chance I could get hold of a hunchentoot release from approx two months
ago?

thanks,

Tiarnan


From edi at agharta.de  Wed May 23 14:19:50 2007
From: edi at agharta.de (Edi Weitz)
Date: Wed, 23 May 2007 16:19:50 +0200
Subject: [hunchentoot-devel] Re: [flexi-streams-devel] Flexi-streams
	test suite failing on OpenMCL
In-Reply-To: <ea7fafc0705230312w58c29d67p121c869c8c52028@mail.gmail.com>
	(Tiarnan O'Corrain's message of "Wed, 23 May 2007 11:12:36 +0100")
References: <ea7fafc0705211332o29e3be01t8fd14ca8922e5c43@mail.gmail.com>
	<uk5uzeuoz.fsf@agharta.de>
	<ea7fafc0705230312w58c29d67p121c869c8c52028@mail.gmail.com>
Message-ID: <ud50rfwqh.fsf@agharta.de>

On Wed, 23 May 2007 11:12:36 +0100, "Tiarnan O'Corrain" <ocorrain at gmail.com> wrote:

> The nuclear option?

Yes.  I don't necessarily /want/ to do that, but I can't test and
maintain an OpenMCL version, so we either need someone who takes care
of that or we'd better be honest and don't purport to support OpenMCL.

> I recall hunchentoot working on OpenMCL a few months ago -- I was
> using it for some development (deployment to be on FreeBSD/cmucl),
> without any problems.  Then the Mac got sick for a while, and when I
> got it back, hunchentoot was broken.

Are you still using the same OpenMCL version you used at that time?

> I'll try it out on the version you suggested later on today -- I'm
> using Mac OS X 10.4, so perhaps that has something to do with it.
> Another possibility would be to ask Gary Byers on the OpenMCL
> mailing list -- I'll do that when I get a chance to look at the
> problem in more detail.

OK, I'll wait for that.


From edi at agharta.de  Wed May 23 14:20:33 2007
From: edi at agharta.de (Edi Weitz)
Date: Wed, 23 May 2007 16:20:33 +0200
Subject: [hunchentoot-devel] Re: [flexi-streams-devel] Flexi-streams
	test suite failing on OpenMCL
In-Reply-To: <ea7fafc0705230651l40e4f58j8c0f7e9c4c5a87bd@mail.gmail.com>
	(Tiarnan O'Corrain's message of "Wed, 23 May 2007 14:51:43 +0100")
References: <ea7fafc0705211332o29e3be01t8fd14ca8922e5c43@mail.gmail.com>
	<uk5uzeuoz.fsf@agharta.de>
	<ea7fafc0705230312w58c29d67p121c869c8c52028@mail.gmail.com>
	<ea7fafc0705230651l40e4f58j8c0f7e9c4c5a87bd@mail.gmail.com>
Message-ID: <u8xbffwpa.fsf@agharta.de>

On Wed, 23 May 2007 14:51:43 +0100, "Tiarnan O'Corrain" <ocorrain at gmail.com> wrote:

> any chance I could get hold of a hunchentoot release from approx two
> months ago?

For older releases see the last sentences of the download section:

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


From edi at agharta.de  Wed May 23 14:20:57 2007
From: edi at agharta.de (Edi Weitz)
Date: Wed, 23 May 2007 16:20:57 +0200
Subject: [hunchentoot-devel] (Non)-Bug in subclassing dav:file-resource
In-Reply-To: <1179928018.6446.2.camel@localhost.localdomain> (Ralf Mattes's
	message of "Wed, 23 May 2007 15:46:58 +0200")
References: <1179928018.6446.2.camel@localhost.localdomain>
Message-ID: <u4pm3fwom.fsf@agharta.de>

On Wed, 23 May 2007 15:46:58 +0200, Ralf Mattes <rm at seid-online.de> wrote:

> Ok, I looked closer at the code for authorized-file-resource - I
> forgot to implement accept-request-p ... after fixing this
> everything works fine now.

Good... :)


From ch-tbnl at bobobeach.com  Wed May 23 14:55:54 2007
From: ch-tbnl at bobobeach.com (Cyrus Harmon)
Date: Wed, 23 May 2007 07:55:54 -0700
Subject: [hunchentoot-devel] Re: [flexi-streams-devel] Flexi-streams test
	suite failing on OpenMCL
In-Reply-To: <ea7fafc0705230312w58c29d67p121c869c8c52028@mail.gmail.com>
References: <ea7fafc0705211332o29e3be01t8fd14ca8922e5c43@mail.gmail.com>
	<uk5uzeuoz.fsf@agharta.de>
	<ea7fafc0705230312w58c29d67p121c869c8c52028@mail.gmail.com>
Message-ID: <CC2063DE-C1F7-4F79-B050-34667F19179B@bobobeach.com>


On May 23, 2007, at 3:12 AM, Tiarnan O'Corrain wrote:
> The unfortunate upshot of this (for me, at least), is that hunchentoot
> will no longer
> be deployable on a free Mac lisp, as SBCL/Mac doesn't have  
> threading, and
> CMUCL/Mac is missing the multiprocessing package.

sbcl/macos/x86 does have threading and it works quite nicely with  
hunchentoot, at least for my development work. Of course you have to  
build your own SBCL with threading support enabled, but that's true  
for all of the sbcl threads ports. Of course you're correct that  
there is no thread support for sbcl/macos/ppc.




From viktor.leis at googlemail.com  Wed May 23 14:56:54 2007
From: viktor.leis at googlemail.com (Viktor Leis)
Date: Wed, 23 May 2007 16:56:54 +0200
Subject: [hunchentoot-devel] Uploaded files are sometimes incomplete
Message-ID: <dd2a61510705230756s5072a309v42361ccce2e659ae@mail.gmail.com>

Hi,

when using Hunchentoot with SBCL on debian behind mod_lisp and Apache
1 for video file uploading, the uploads randomly fail (the file is
incomplete). Warning on the server:
WARNING: 28369838 octets of stray data after form-data sent by client.

This happens most of the time if the server is on the same machine as
the uploading browser, less often if the server is on a different
machine in the LAN and only sometimes if the upload goes through the
internet. Using Apache2 seems to fix the problem. Any ideas what the
problem may be?

Thanks,
Viktor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20070523/392eea4f/attachment.html>

From gwking at metabang.com  Wed May 23 16:18:35 2007
From: gwking at metabang.com (Gary King)
Date: Wed, 23 May 2007 12:18:35 -0400
Subject: [hunchentoot-devel] Getting MD5
Message-ID: <D8753F73-3CF8-488D-8EDD-15F0704DAEB9@metabang.com>

Hi y'all,

I'm looking for MD5 source. Kevin Rosenberg's link is currently  
inaccessible (I've asked him too and I'm sure he'll fix it soon but  
I'm sometimes impatient! >smile<).

thanks,
--
Gary Warren King, metabang.com
Cell: (413) 885 9127
Fax: (206) 338-4052
gwkkwg on Skype * garethsan on AIM






From xach at xach.com  Wed May 23 16:21:49 2007
From: xach at xach.com (Zach Beane)
Date: Wed, 23 May 2007 12:21:49 -0400
Subject: [hunchentoot-devel] Getting MD5
In-Reply-To: <D8753F73-3CF8-488D-8EDD-15F0704DAEB9@metabang.com>
References: <D8753F73-3CF8-488D-8EDD-15F0704DAEB9@metabang.com>
Message-ID: <20070523162149.GX30872@xach.com>

On Wed, May 23, 2007 at 12:18:35PM -0400, Gary King wrote:
> Hi y'all,
> 
> I'm looking for MD5 source. Kevin Rosenberg's link is currently  
> inaccessible (I've asked him too and I'm sure he'll fix it soon but  
> I'm sometimes impatient! >smile<).

You can get 1.8.5 from http://xach.com/tmp/md5-1.8.5.tar.gz for a
while.

Zach


From rm at seid-online.de  Wed May 23 16:35:49 2007
From: rm at seid-online.de (Ralf Mattes)
Date: Wed, 23 May 2007 18:35:49 +0200
Subject: [hunchentoot-devel] [CL-WEBDAV] Property behaviour
Message-ID: <1179938149.6446.13.camel@localhost.localdomain>

Ok, i just had a closer look at the property code - too me it seems as
if there's a lot of unnecessary redundance in the code. For example:

 A PROPGET for all properties of a resource will result in a call to
'collect-all-properties' that will call 'all-property-designators' which
will result (at the end of a long call chain) in a call to
'get-dead-properties'. After that the same 'get-dead-properties' is
called for each property again. Now, according to the documentation
'get-dead-properties' is supposed to return _all_ dead properties so it
looks as if we do some extra work here ;-)


 Cheers, RalfD



From gwking at metabang.com  Wed May 23 18:06:04 2007
From: gwking at metabang.com (Gary King)
Date: Wed, 23 May 2007 14:06:04 -0400
Subject: [hunchentoot-devel] Re: Getting MD5
In-Reply-To: <20070523162948.GA9277@rosenberg.net>
References: <D8753F73-3CF8-488D-8EDD-15F0704DAEB9@metabang.com>
	<20070523162948.GA9277@rosenberg.net>
Message-ID: <BCAE6D97-C360-40BE-82EF-3F8CE19EA5B1@metabang.com>

Hmm,

It does now. I didn't this morning... sorry for overreacting! (and  
thanks)

On May 23, 2007, at 12:29 PM, Kevin Rosenberg wrote:

> Gary King wrote:
>> I'm looking for MD5 source. Kevin Rosenberg's link is currently
>> inaccessible (I've asked him too and I'm sure he'll fix it soon but
>> I'm sometimes impatient! >smile<).
>
> Hi Gary,
>
> So http://files.b9.com/md5/ doesn't work for you?
>
> -- 
> Kevin Rosenberg
> kevin at hypershots.com
>

--
Gary Warren King, metabang.com
Cell: (413) 885 9127
Fax: (206) 338-4052
gwkkwg on Skype * garethsan on AIM






From edi at agharta.de  Thu May 24 07:23:52 2007
From: edi at agharta.de (Edi Weitz)
Date: Thu, 24 May 2007 09:23:52 +0200
Subject: [hunchentoot-devel] [CL-WEBDAV] Property behaviour
In-Reply-To: <1179938149.6446.13.camel@localhost.localdomain> (Ralf Mattes's
	message of "Wed, 23 May 2007 18:35:49 +0200")
References: <1179938149.6446.13.camel@localhost.localdomain>
Message-ID: <u1wh6y99z.fsf@agharta.de>

On Wed, 23 May 2007 18:35:49 +0200, Ralf Mattes <rm at seid-online.de> wrote:

> A PROPGET for all properties of a resource

I assume you mean PROPFIND.

> will result in a call to 'collect-all-properties' that will call
> 'all-property-designators' which will result (at the end of a long
> call chain) in a call to 'get-dead-properties'. After that the same
> 'get-dead-properties' is called for each property again.

No.  GET-DEAD-PROPERTIES is called once for each /resource/ (not
property) if the "Depth" header is not 0 - see transcript below.  This
has to be done because each resource can have a different set of dead
properties.  At least that's how I'm reading the spec.

> Now, according to the documentation 'get-dead-properties' is
> supposed to return _all_ dead properties so it looks as if we do
> some extra work here ;-)

I don't think so.

Cheers,
Edi.




  CL-USER 1 > (defmethod print-object ((resource dav:file-resource) stream)
                ;; for the TRACE output
                (print-unreadable-object (resource stream :type t)
                  (format stream " ~S" (dav::resource-name resource))))
  #<STANDARD-METHOD PRINT-OBJECT NIL (CL-WEBDAV:FILE-RESOURCE T) 200BDDEF>

  CL-USER 2 > (merge-pathnames "test/*.*" dav:*file-resource-base-path-namestring*)
  #P"c:/tmp/test/*.*"

  CL-USER 3 > (directory *)
  (#P"c:/tmp/test/foo" #P"c:/tmp/test/bar")

  CL-USER 4 > (push (dav:create-dav-dispatcher 'dav:file-resource) tbnl:*dispatch-table*)
  (#<Closure ((METHOD CL-WEBDAV:CREATE-DAV-DISPATCHER (SYMBOL)) . 1) 200F6252> HUNCHENTOOT:DEFAULT-DISPATCHER)

  CL-USER 5 > (trace dav::get-dead-properties)
  (CL-WEBDAV:GET-DEAD-PROPERTIES)

  CL-USER 6 > (tbnl:start-server :port 4242)
  #<HUNCHENTOOT::SERVER 20090CFB>

  CL-USER 7 > (nth-value 1 (drakma:http-request "http://localhost:4242/test/"
                                                :method :propfind
                                                :additional-headers '(("Depth" . "1"))))
  207

  CL-USER 8 > (nth-value 1 (drakma:http-request "http://localhost:4242/test/"
                                                :method :propfind
                                                :additional-headers '(("Depth" . "0"))))
  207


For the first request, the TRACE window looks like this:

  0 CL-WEBDAV:GET-DEAD-PROPERTIES > ...
    >> CL-WEBDAV:RESOURCE : #<CL-WEBDAV:FILE-RESOURCE  "test">
  0 CL-WEBDAV:GET-DEAD-PROPERTIES < ...
    << VALUE-0 : NIL
    << VALUE-1 : NIL
  0 CL-WEBDAV:GET-DEAD-PROPERTIES > ...
    >> CL-WEBDAV:RESOURCE : #<CL-WEBDAV:FILE-RESOURCE  "foo">
  0 CL-WEBDAV:GET-DEAD-PROPERTIES < ...
    << VALUE-0 : NIL
    << VALUE-1 : NIL
  0 CL-WEBDAV:GET-DEAD-PROPERTIES > ...
    >> CL-WEBDAV:RESOURCE : #<CL-WEBDAV:FILE-RESOURCE  "bar">
  0 CL-WEBDAV:GET-DEAD-PROPERTIES < ...
    << VALUE-0 : NIL
    << VALUE-1 : NIL

For the second request, the TRACE window looks like this:

  0 CL-WEBDAV:GET-DEAD-PROPERTIES > ...
    >> CL-WEBDAV:RESOURCE : #<CL-WEBDAV:FILE-RESOURCE  "test">
  0 CL-WEBDAV:GET-DEAD-PROPERTIES < ...
    << VALUE-0 : NIL
    << VALUE-1 : NIL


From edi at agharta.de  Thu May 24 07:47:15 2007
From: edi at agharta.de (Edi Weitz)
Date: Thu, 24 May 2007 09:47:15 +0200
Subject: [hunchentoot-devel] Uploaded files are sometimes incomplete
In-Reply-To: <dd2a61510705230756s5072a309v42361ccce2e659ae@mail.gmail.com>
	(Viktor Leis's message of "Wed, 23 May 2007 16:56:54 +0200")
References: <dd2a61510705230756s5072a309v42361ccce2e659ae@mail.gmail.com>
Message-ID: <umyzu8xz0.fsf@agharta.de>

On Wed, 23 May 2007 16:56:54 +0200, "Viktor Leis" <viktor.leis at googlemail.com> wrote:

> when using Hunchentoot with SBCL on debian behind mod_lisp and
> Apache 1 for video file uploading, the uploads randomly fail (the
> file is incomplete). Warning on the server: WARNING: 28369838 octets
> of stray data after form-data sent by client.
>
> This happens most of the time if the server is on the same machine
> as the uploading browser, less often if the server is on a different
> machine in the LAN and only sometimes if the upload goes through the
> internet. Using Apache2 seems to fix the problem. Any ideas what the
> problem may be?

Hmm, hmm, hmm.  I seem to remember I had the same problem some time
ago but couldn't really resolve it.  (Or maybe I could, dunno.  My age
shows...)

Anyway, what I /think/ is happening is that for some reason when the
stream is read character by character within the RFC2388 library, Lisp
at some point (and this is non-deterministic unfortunately) believes
that it is done with the stream (EOF) although it shouldn't.

So, this only happens with mod_lisp and Apache 1 for you?  Are you
using the newest version of mod_lisp?  Can you reproduce it with
stand-alone Hunchentoot?  Which OS are you on?  If it's Linux, what
kernel are you using?

Sorry, but I don't really have a satisfying answer right now...

Cheers,
Edi.


From rm at seid-online.de  Thu May 24 08:23:20 2007
From: rm at seid-online.de (Ralf Mattes)
Date: Thu, 24 May 2007 10:23:20 +0200
Subject: [hunchentoot-devel] [CL-WEBDAV] Property behaviour
In-Reply-To: <u1wh6y99z.fsf@agharta.de>
References: <1179938149.6446.13.camel@localhost.localdomain>
	<u1wh6y99z.fsf@agharta.de>
Message-ID: <1179995001.6408.7.camel@localhost.localdomain>

On Thu, 2007-05-24 at 09:23 +0200, Edi Weitz wrote:
> On Wed, 23 May 2007 18:35:49 +0200, Ralf Mattes <rm at seid-online.de> wrote:
> 
> > A PROPGET for all properties of a resource
> 
> I assume you mean PROPFIND.

Sorry, yes - I'm testing with cadaver whose PROPFIND command is called
'propget'.

> > will result in a call to 'collect-all-properties' that will call
> > 'all-property-designators' which will result (at the end of a long
> > call chain) in a call to 'get-dead-properties'. After that the same
> > 'get-dead-properties' is called for each property again.
> 
> No.  GET-DEAD-PROPERTIES is called once for each /resource/ (not
> property) if the "Depth" header is not 0 - see transcript below.  This
> has to be done because each resource can have a different set of dead
> properties.  At least that's how I'm reading the spec.
> 

There's nothing wrong with your transcript but it doesn't seem to
contradict what I reported. What I observe is that 'get-dead-properties'
gets called once for the resource and once for each property. 
Now, unless you magically did add some properties to 'foo' and 'bar' you
can't observe this ... ;-)

Cheers, RalfD

> > Now, according to the documentation 'get-dead-properties' is
> > supposed to return _all_ dead properties so it looks as if we do
> > some extra work here ;-)
> 
> I don't think so.
> 
> Cheers,
> Edi.
> 
> 
> 
> 
>   CL-USER 1 > (defmethod print-object ((resource dav:file-resource) stream)
>                 ;; for the TRACE output
>                 (print-unreadable-object (resource stream :type t)
>                   (format stream " ~S" (dav::resource-name resource))))
>   #<STANDARD-METHOD PRINT-OBJECT NIL (CL-WEBDAV:FILE-RESOURCE T) 200BDDEF>
> 
>   CL-USER 2 > (merge-pathnames "test/*.*" dav:*file-resource-base-path-namestring*)
>   #P"c:/tmp/test/*.*"
> 
>   CL-USER 3 > (directory *)
>   (#P"c:/tmp/test/foo" #P"c:/tmp/test/bar")
> 
>   CL-USER 4 > (push (dav:create-dav-dispatcher 'dav:file-resource) tbnl:*dispatch-table*)
>   (#<Closure ((METHOD CL-WEBDAV:CREATE-DAV-DISPATCHER (SYMBOL)) . 1) 200F6252> HUNCHENTOOT:DEFAULT-DISPATCHER)
> 
>   CL-USER 5 > (trace dav::get-dead-properties)
>   (CL-WEBDAV:GET-DEAD-PROPERTIES)
> 
>   CL-USER 6 > (tbnl:start-server :port 4242)
>   #<HUNCHENTOOT::SERVER 20090CFB>
> 
>   CL-USER 7 > (nth-value 1 (drakma:http-request "http://localhost:4242/test/"
>                                                 :method :propfind
>                                                 :additional-headers '(("Depth" . "1"))))
>   207
> 
>   CL-USER 8 > (nth-value 1 (drakma:http-request "http://localhost:4242/test/"
>                                                 :method :propfind
>                                                 :additional-headers '(("Depth" . "0"))))
>   207
> 
> 
> For the first request, the TRACE window looks like this:
> 
>   0 CL-WEBDAV:GET-DEAD-PROPERTIES > ...
>     >> CL-WEBDAV:RESOURCE : #<CL-WEBDAV:FILE-RESOURCE  "test">
>   0 CL-WEBDAV:GET-DEAD-PROPERTIES < ...
>     << VALUE-0 : NIL
>     << VALUE-1 : NIL
>   0 CL-WEBDAV:GET-DEAD-PROPERTIES > ...
>     >> CL-WEBDAV:RESOURCE : #<CL-WEBDAV:FILE-RESOURCE  "foo">
>   0 CL-WEBDAV:GET-DEAD-PROPERTIES < ...
>     << VALUE-0 : NIL
>     << VALUE-1 : NIL
>   0 CL-WEBDAV:GET-DEAD-PROPERTIES > ...
>     >> CL-WEBDAV:RESOURCE : #<CL-WEBDAV:FILE-RESOURCE  "bar">
>   0 CL-WEBDAV:GET-DEAD-PROPERTIES < ...
>     << VALUE-0 : NIL
>     << VALUE-1 : NIL
> 
> For the second request, the TRACE window looks like this:
> 
>   0 CL-WEBDAV:GET-DEAD-PROPERTIES > ...
>     >> CL-WEBDAV:RESOURCE : #<CL-WEBDAV:FILE-RESOURCE  "test">
>   0 CL-WEBDAV:GET-DEAD-PROPERTIES < ...
>     << VALUE-0 : NIL
>     << VALUE-1 : NIL



From rm at seid-online.de  Thu May 24 08:34:03 2007
From: rm at seid-online.de (Ralf Mattes)
Date: Thu, 24 May 2007 10:34:03 +0200
Subject: [hunchentoot-devel] [CL-WEBDAV] Property behaviour
In-Reply-To: <1179995001.6408.7.camel@localhost.localdomain>
References: <1179938149.6446.13.camel@localhost.localdomain>
	<u1wh6y99z.fsf@agharta.de>
	<1179995001.6408.7.camel@localhost.localdomain>
Message-ID: <1179995643.6408.15.camel@localhost.localdomain>

Just as a follow-up: 

 I'm mainly concerned with PROPFIND on plain resources for now.
I think the following code in 'properties.lisp' does extra work:


  (dolist (property-designator 
	(cond ((eql property-designators t)
        	       (all-property-designators resource))   <---[1]
               (t property-designators)))

      (multiple-value-bind (status property)
          (propstat resource property-designator show-content) <--- [2]


For a PROPFIND on ALL properties [1] will call 'get-dead-properties'.
Then, for each property (in the dolist body) [2] will call
'get-dead-properties' again 
 (propstat->get-property->get-dead-property->get-dead-properties).

I hope I've made myself a bit clearer now.

 Cheers, RalfD



From edi at agharta.de  Thu May 24 08:35:02 2007
From: edi at agharta.de (Edi Weitz)
Date: Thu, 24 May 2007 10:35:02 +0200
Subject: [hunchentoot-devel] [CL-WEBDAV] Property behaviour
In-Reply-To: <1179995001.6408.7.camel@localhost.localdomain> (Ralf Mattes's
	message of "Thu, 24 May 2007 10:23:20 +0200")
References: <1179938149.6446.13.camel@localhost.localdomain>
	<u1wh6y99z.fsf@agharta.de>
	<1179995001.6408.7.camel@localhost.localdomain>
Message-ID: <uirai8vrd.fsf@agharta.de>

On Thu, 24 May 2007 10:23:20 +0200, Ralf Mattes <rm at seid-online.de> wrote:

> What I observe is that 'get-dead-properties' gets called once for
> the resource and once for each property.

Ah, now I see.  You mean the call to GET-DEAD-PROPERTIES in
GET-DEAD-PROPERTY, right?

Yes, in my original code GET-DEAD-PROPERTY was one of the generic
functions you could specialize.  When I cleaned up the code for
release, I removed it because I deemed it kind of redundant and I
generally favor convenience over speed optimizations.  Of course, if
you think this will be a huge performance hog for you, we can
re-introduce this generic function and make the current implementation
the default.  That's a very simple change.


From viktor.leis at googlemail.com  Thu May 24 09:48:06 2007
From: viktor.leis at googlemail.com (Viktor Leis)
Date: Thu, 24 May 2007 11:48:06 +0200
Subject: [hunchentoot-devel] Uploaded files are sometimes incomplete
In-Reply-To: <umyzu8xz0.fsf@agharta.de>
References: <dd2a61510705230756s5072a309v42361ccce2e659ae@mail.gmail.com>
	<umyzu8xz0.fsf@agharta.de>
Message-ID: <dd2a61510705240248u5adde171w439d353c4dcd8a23@mail.gmail.com>

2007/5/24, Edi Weitz <edi at agharta.de>:
>
> On Wed, 23 May 2007 16:56:54 +0200, "Viktor Leis" <
> viktor.leis at googlemail.com> wrote:
>
> > when using Hunchentoot with SBCL on debian behind mod_lisp and
> > Apache 1 for video file uploading, the uploads randomly fail (the
> > file is incomplete). Warning on the server: WARNING: 28369838 octets
> > of stray data after form-data sent by client.
> >
> > This happens most of the time if the server is on the same machine
> > as the uploading browser, less often if the server is on a different
> > machine in the LAN and only sometimes if the upload goes through the
> > internet. Using Apache2 seems to fix the problem. Any ideas what the
> > problem may be?
>
> Hmm, hmm, hmm.  I seem to remember I had the same problem some time
> ago but couldn't really resolve it.  (Or maybe I could, dunno.  My age
> shows...)
>
> Anyway, what I /think/ is happening is that for some reason when the
> stream is read character by character within the RFC2388 library, Lisp
> at some point (and this is non-deterministic unfortunately) believes
> that it is done with the stream (EOF) although it shouldn't.
>
> So, this only happens with mod_lisp and Apache 1 for you?  Are you
> using the newest version of mod_lisp?  Can you reproduce it with
> stand-alone Hunchentoot?  Which OS are you on?  If it's Linux, what
> kernel are you using?
>
Yes, I have only observed this behavior with Apache 1, which is
unfortunately my prefered platform. Also stand-alone Hunchentoot seems
to work fine. I'm using debians mod_lisp in version 2.43 which is the
newest version I think. I'm using the standard debian linux kernel in
version 2.6.18 and the newest SBCL.

Bye,
Viktor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20070524/d1923073/attachment.html>

From coffeemug at gmail.com  Fri May 25 03:35:52 2007
From: coffeemug at gmail.com (Slava Akhmechet)
Date: Thu, 24 May 2007 23:35:52 -0400
Subject: [hunchentoot-devel] (session-cookie-value) should be exported?
Message-ID: <87fy5l8tif.fsf@gmail.com>

I'm writing code to rewrite URLs in JavaScript to support AJAX
requests for clients that have cookies disabled. It appears that the
right thing to send would be the value returned by
(session-cookie-value), not the value returned by the exported
(session-string). Should 'session-cookie-value' be exported from the
'hunchentoot' package?

-- 
Regards,
Slava Akhmechet.


From edi at agharta.de  Fri May 25 10:37:01 2007
From: edi at agharta.de (Edi Weitz)
Date: Fri, 25 May 2007 12:37:01 +0200
Subject: [hunchentoot-devel] (session-cookie-value) should be exported?
In-Reply-To: <87fy5l8tif.fsf@gmail.com> (Slava Akhmechet's message of "Thu,
	24 May 2007 23:35:52 -0400")
References: <87fy5l8tif.fsf@gmail.com>
Message-ID: <uejl56vg2.fsf@agharta.de>

On Thu, 24 May 2007 23:35:52 -0400, Slava Akhmechet <coffeemug at gmail.com> wrote:

> I'm writing code to rewrite URLs in JavaScript to support AJAX
> requests for clients that have cookies disabled. It appears that the
> right thing to send would be the value returned by
> (session-cookie-value), not the value returned by the exported
> (session-string). Should 'session-cookie-value' be exported from the
> 'hunchentoot' package?

Yes, you're right.  And SESSION-STRING is actually not needed.  Will
be changed in the next release.

Thanks,
Edi.


From lstaflin at gmail.com  Fri May 25 11:01:07 2007
From: lstaflin at gmail.com (Lennart Staflin)
Date: Fri, 25 May 2007 13:01:07 +0200
Subject: [hunchentoot-devel] Hunchentoot and OpenMCL
Message-ID: <e5134fd00705250401w200b69d4l3203651478b0af4f@mail.gmail.com>

Hi,
I have been using OpenMCL and portable aserve. I ran into some trouble
with character encoding, and after looking at the code decided that it
would be difficult to fix. I am now considering alternatives.

I read somewhere that Hunchentoot runs on OpenMCL so I'm going to try it out.

Any experience with running Hunchentoot on OpenMCL, specially the
bleeding edge OpenMCL?

Any experience converting a project from aserve to Hunchentoot?

Also I ran into a compile problem:

;Compiler warnings :
;   Undefined function CCL::DEQUEUE-TIMER-REQUEST, in INVOKE-WITH-TIMEOUT.
;   Undefined function CCL::ENQUEUE-TIMER-REQUEST, in INVOKE-WITH-TIMEOUT.
;   Undefined function CCL::MAKE-TIMER-REQUEST, in INVOKE-WITH-TIMEOUT.

from port-mcl.lisp:

(defun invoke-with-timeout (seconds bodyfn timeoutfn)
  "Executes the function \(with no arguments) BODY-FN and returns
its results but stops execution after DURATION seconds and then
instead calls TIMEOUT-FN and returns its values."
  ;; from Portable AllegroServe
  (block timeout
    (let* ((timer (ccl::make-timer-request seconds
                                           #'(lambda ()
                                               (return-from timeout
(funcall timeoutfn))))))
      (ccl::enqueue-timer-request timer)
      (unwind-protect (funcall bodyfn)
	(ccl::dequeue-timer-request timer)))))


Probably the timer functions have been removed in some of the later
versions of OpenMCL. Unless someone has a fix already I will dig into
this.


-- 
//Lennart Staflin


From edi at agharta.de  Fri May 25 11:39:13 2007
From: edi at agharta.de (Edi Weitz)
Date: Fri, 25 May 2007 13:39:13 +0200
Subject: [hunchentoot-devel] Hunchentoot and OpenMCL
In-Reply-To: <e5134fd00705250401w200b69d4l3203651478b0af4f@mail.gmail.com>
	(Lennart Staflin's message of "Fri, 25 May 2007 13:01:07 +0200")
References: <e5134fd00705250401w200b69d4l3203651478b0af4f@mail.gmail.com>
Message-ID: <uwsyx5dzy.fsf@agharta.de>

Hi,

On Fri, 25 May 2007 13:01:07 +0200, "Lennart Staflin" <lstaflin at gmail.com> wrote:

> I have been using OpenMCL and portable aserve. I ran into some
> trouble with character encoding, and after looking at the code
> decided that it would be difficult to fix. I am now considering
> alternatives.
>
> I read somewhere that Hunchentoot runs on OpenMCL so I'm going to
> try it out.
>
> Any experience with running Hunchentoot on OpenMCL, specially the
> bleeding edge OpenMCL?

You're asking at the right moment... :)

It seems we currently have problems with OpenMCL and I can't do much
about it as I don't have a Mac.  If you check the mailing list
archives of tbnl-devel and flexi-streams-devel of this month, you'll
find all the details.

I was close to removing OpenMCL support from Hunchentoot, but if you
can help fixing the issues, that's fine of course.

> Any experience converting a project from aserve to Hunchentoot?

Not me.

> Probably the timer functions have been removed in some of the later
> versions of OpenMCL. Unless someone has a fix already I will dig
> into this.

Good.

Thanks in advance,
Edi.


From edi at agharta.de  Fri May 25 11:41:55 2007
From: edi at agharta.de (Edi Weitz)
Date: Fri, 25 May 2007 13:41:55 +0200
Subject: [hunchentoot-devel] New release 0.11.0
Message-ID: <usl9l5dvg.fsf@agharta.de>

ChangeLog

  Version 0.11.0
  2007-05-25
  Added server names and coupled them with easy handlers (suggested by Mac Chan)
  Exported SESSION-COOKIE-VALUE instead of SESSION-STRING (suggested by Slava Akhmechet)
  Documentation fixes (thanks to Victor Kryukov and Igor Plekhov)

Download

  http://weitz.de/files/hunchentoot.tar.gz

Cheers,
Edi.


From tschaef at sbcglobal.net  Fri May 25 13:47:57 2007
From: tschaef at sbcglobal.net (Timothy Schaeffer)
Date: Fri, 25 May 2007 06:47:57 -0700 (PDT)
Subject: [hunchentoot-devel] Custom types for easy handler.
Message-ID: <697843.97803.qm@web82304.mail.mud.yahoo.com>

Hello all,

I propose that the types for easy-handlers be extensible by the users.  I have pieces of markup which are used throughout our site which collect information from several fields into a class (in our case tied to a database with clsql).  The names of the fields are related, but diffierent from the lists, arrays and hashes of the easy-handlers,  Dates and addresses are two good examples, but there are others.  I would like to be able to teach the easy handler to collect these for me and pass them as parameters.  This cannot be done with functions as the :parameter-type because the functions passed as :parameter-type do not take the parameter name.

There are two ways I think this could be done:

- The easier way: add a :paramater-reader arg to the parameter description, and if passed use it in lieu of the ((post|get)-)?parameter functions in compute-parameter. The following might do it (untested):

(defun compute-parameter (parameter-name parameter-type request-type 
                                            &optional parameter-reader)   ; <=====
  "Computes and returns the parameter\(s) called PARAMETER-NAME
and converts it/them according to the value of PARAMETER-TYPE.
REQUEST-TYPE is one of :GET, :POST, or :BOTH."
  (when (member parameter-type '(list array hash-table))
    (setq parameter-type (list parameter-type 'string)))
  (let ((parameter-reader (or parameter-reader   ; <====
                           (ecase request-type
                              (:get #'get-parameter)
                              (:post #'post-parameter)
                              (:both #'parameter)))        )
        (parameters (and (listp parameter-type)
                         (case request-type
                           (:get (get-parameters))
                           (:post (post-parameters))
                           (:both (append (get-parameters) (post-parameters)))))))
    (cond ((atom parameter-type)
           (compute-simple-parameter parameter-name parameter-type parameter-reader))
          ((and (null (cddr parameter-type))
                (eq (first parameter-type) 'list))
           (compute-list-parameter parameter-name (second parameter-type) parameters))
          ((and (null (cddr parameter-type))
                (eq (first parameter-type) 'array))
           (compute-array-parameter parameter-name (second parameter-type) parameters))
          ((and (null (cddddr parameter-type))
                (eq (first parameter-type) 'hash-table))
           (compute-hash-table-parameter parameter-name (second parameter-type) parameters
                                         (or (third parameter-type) 'string)
                                         (or (fourth parameter-type) 'equal)))
          (t (error "Don't know what to do with parameter type ~S." parameter-type)))))

(defun make-defun-parameter (description default-parameter-type default-request-type)
  "Creates a keyword parameter to be used by DEFINE-EASY-HANDLER.
DESCRIPTION is one of the elements of DEFINE-EASY-HANDLER's
LAMBDA-LIST and DEFAULT-PARAMETER-TYPE and DEFAULT-REQUEST-TYPE
are the global default values."
  (when (atom description)
    (setq description (list description)))
  (destructuring-bind (parameter-name &key (real-name (compute-real-name parameter-name))
                                           parameter-type init-form request-type      parameter-reader   )         ; <====
      description
    `(,parameter-name (or (and (boundp '*request*)
                               (compute-parameter ,real-name
                                                  ,(or parameter-type default-parameter-type)
                                                  ,(or request-type default-request-type)))
                          ,init-form))))

(This just occurred to me: request-type could be a function, with an obvious change to the ecase.  This is a little more confusing but consistent with what parameter-type does---so it has the force of precedent---and requires a smaller change to the code.).

- The extensive way:   Change the  cond in compute-parameter to a switch via a hash table, whose values are the conversion handlers (or a cons with reader and converter).  It may need two hash tables: one for simple type names (type is a symbol) and one for aggregates, (type is a cons, and switch on the first element).  Create a macro, define-easy-type, or something, to populate the tables, and use it within easy-handlers.lisp to populate it with those which are now hardcoded in the cond and case switches.  Users can then use the macro to define their own types.

- Another way: like above, but use methods instead of hash tables.  This seems possible, but I'd have to think some more about it.


BTW: why the checks for null CDDRs and CDDDDRs in compute-parameter?  Is this just nice, or are they essential?

If your interested in the second, I will work something up and send in a patch.  I do not think it would break any existing code which did not peak too far into the easy-handlers stuff.

Let me know what you think.

Tim S

P.S.:
Hunchentoot is a pleasure to work with!
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20070525/7175fee1/attachment.html>

From lstaflin at gmail.com  Fri May 25 16:07:33 2007
From: lstaflin at gmail.com (Lennart Staflin)
Date: Fri, 25 May 2007 18:07:33 +0200
Subject: [hunchentoot-devel] Hunchentoot and OpenMCL
In-Reply-To: <uwsyx5dzy.fsf@agharta.de>
References: <e5134fd00705250401w200b69d4l3203651478b0af4f@mail.gmail.com>
	<uwsyx5dzy.fsf@agharta.de>
Message-ID: <e5134fd00705250907g1e079fb1ie324b03ca557a993@mail.gmail.com>

On 5/25/07, Edi Weitz <edi at agharta.de> wrote:
> Hi,
>

> You're asking at the right moment... :)
>
> It seems we currently have problems with OpenMCL and I can't do much
> about it as I don't have a Mac.  If you check the mailing list
> archives of tbnl-devel and flexi-streams-devel of this month, you'll
> find all the details.
>

Flexi-streams passes all its tests on the latest OpenMCL, I don't
think that is the problem.


> I was close to removing OpenMCL support from Hunchentoot, but if you
> can help fixing the issues, that's fine of course.
>
> > Any experience converting a project from aserve to Hunchentoot?
>
> Not me.
>
> > Probably the timer functions have been removed in some of the later
> > versions of OpenMCL. Unless someone has a fix already I will dig
> > into this.

Or possibly these functions where never in OpenMCL. I think these
functions (ccl::make-timer-request etc.) are defined in acl-compat,
and some how never made it over to port-mcl. They are in a file called
mcl-timers.lisp in acl-compat. Perhaps, if licensing allows, you could
include that file.

Reading the mailing list archive, I noticed another problem that I also had.

  ... i get an error that  says: Unknown http return code: 500

I have tracked this down. It is not related to flexi-streams, but to a
defconstant in specials.lisp:

  (defconstant +http-reason-phrase-map+ (make-hash-table)

When the file is complied and loaded that hash table is empty. I
haven't checked with the OpenMCL developers, but I think this might be
invoking undefined behavior.

CLHS: "An implementation may choose to evaluate the value-form at
compile time, load time, or both."

If the compiler evaluates the (make-hash-table) both at compile time
and load time, and optimizes away the constant lookup (directly uses
that hash table as a literal) in the setter forms. The result would be
as observed in openmcl.

I think either of these would work:

 (defparameter +http-reason-phrase-map+ (make-hash-table)
 (defconstant +http-reason-phrase-map+ '#.(make-hash-table)

With these changes I can now get the test examples to work.

-- 
//Lennart Staflin


From edi at agharta.de  Fri May 25 16:41:25 2007
From: edi at agharta.de (Edi Weitz)
Date: Fri, 25 May 2007 18:41:25 +0200
Subject: [hunchentoot-devel] Hunchentoot and OpenMCL
In-Reply-To: <e5134fd00705250907g1e079fb1ie324b03ca557a993@mail.gmail.com>
	(Lennart Staflin's message of "Fri, 25 May 2007 18:07:33 +0200")
References: <e5134fd00705250401w200b69d4l3203651478b0af4f@mail.gmail.com>
	<uwsyx5dzy.fsf@agharta.de>
	<e5134fd00705250907g1e079fb1ie324b03ca557a993@mail.gmail.com>
Message-ID: <uhcq06ekq.fsf@agharta.de>

On Fri, 25 May 2007 18:07:33 +0200, "Lennart Staflin" <lstaflin at gmail.com> wrote:

> Flexi-streams passes all its tests on the latest OpenMCL, I don't
> think that is the problem.

Yes, that's what I also observed, but we had different reports
regarding earlier versions.

> Or possibly these functions where never in OpenMCL. I think these
> functions (ccl::make-timer-request etc.) are defined in acl-compat,
> and some how never made it over to port-mcl. They are in a file
> called mcl-timers.lisp in acl-compat. Perhaps, if licensing allows,
> you could include that file.

The file doesn't seem to have a license - which is true for all of
ACL-COMPAT as far as I can tell.

Besides, that doesn't look like the real strategy to me.  I'd rather
not have code in Hunchentoot which adds basic functionality to
OpenMCL.  If there's no better way to overcome this problem, I think
Hunchentoot should require ACL-COMPAT on OpenMCL.

> I have tracked this down. It is not related to flexi-streams, but to
> a defconstant in specials.lisp:
>
>   (defconstant +http-reason-phrase-map+ (make-hash-table)
>
> When the file is complied and loaded that hash table is empty. I
> haven't checked with the OpenMCL developers, but I think this might
> be invoking undefined behavior.

Ah, thanks, I think you're right.  I'll change that.

Thanks,
Edi.


From edi at agharta.de  Fri May 25 16:55:55 2007
From: edi at agharta.de (Edi Weitz)
Date: Fri, 25 May 2007 18:55:55 +0200
Subject: [hunchentoot-devel] New release 0.11.1 (Was: Hunchentoot and
	OpenMCL)
In-Reply-To: <uhcq06ekq.fsf@agharta.de> (Edi Weitz's message of "Fri, 25 May
	2007 18:41:25 +0200")
References: <e5134fd00705250401w200b69d4l3203651478b0af4f@mail.gmail.com>
	<uwsyx5dzy.fsf@agharta.de>
	<e5134fd00705250907g1e079fb1ie324b03ca557a993@mail.gmail.com>
	<uhcq06ekq.fsf@agharta.de>
Message-ID: <ud50o6dwk.fsf_-_@agharta.de>

On Fri, 25 May 2007 18:41:25 +0200, Edi Weitz <edi at agharta.de> wrote:

> Ah, thanks, I think you're right.  I'll change that.

OK, I've made a new release which now hopefully works with the latest
OpenMCL release.  Please check.

Cheers,
Edi.


From stesch at no-spoon.de  Fri May 25 20:09:51 2007
From: stesch at no-spoon.de (Stefan Scholl)
Date: Fri, 25 May 2007 22:09:51 +0200
Subject: [hunchentoot-devel] Lisp server page for hunchentoot
In-Reply-To: <4877ae640705221810y6773ad26m37ccff9b647b0578@mail.gmail.com>
References: <4877ae640705221810y6773ad26m37ccff9b647b0578@mail.gmail.com>
Message-ID: <20070525200951.GW4405@parsec.no-spoon.de>

On 2007-05-22 18:10:35, Mac Chan wrote:
> * Why another template module?
> 
> There are indeed a lot of template libraries including CL-EMB, Edi's
> own HTML-TEMPLATE, etc. But these libraries are obstinate in that they
> require you to construct and pass the `environment' variable in order
> to generate the dynamic content.

Nope. CL-EMB is based on John Wiseman's LSP, too. The special
template tags are an additional way to write the templates.

The first example on
http://common-lisp.net/project/cl-emb/examples.html even uses
CL-WHO. :-)


> Secondly, I found that the @if @else template extensions/add-ons are
> often too limited in expressive power.

They are in CL-EMB to limit the expressive power in cases you
need to. Like letting a non-Lisper design HTML.


> where it occurs. With lsp, the line number is lost when we use the
> built-in lisp reader to read the form. However you can use
> `show-lsp-form' in the REPL to examine the code when you encounter an
> error.

PPRINT-EMB-FUNCTION in CL-EMB.


-- 
Web (en): http://www.no-spoon.de/ -*- Web (de): http://www.frell.de/


From emailmac at gmail.com  Sat May 26 10:24:31 2007
From: emailmac at gmail.com (Mac Chan)
Date: Sat, 26 May 2007 03:24:31 -0700
Subject: [hunchentoot-devel] gzip-encoding
Message-ID: <4877ae640705260324p1e925816x6929678c31d1a5b6@mail.gmail.com>

With this web 2.0 thing, nowadays it's not uncommon to have javascript
library weighting over 500k (with extreme case like dojo which adds up
to several megabytes).

If you google a bit you'll find that this doesn't concern the toolkit
authors because they'll say that if you minimize (eliminate
whitespaces) the javascript file and turn on gzip encoding it's a
non-issue.

It was a low-hanging fruit to add gzip-encoding to hunchentoot since
the hard work has already been done by Edi's (flexi-stream), Zach
(Salza 1) and Sean Ross (gzip-stream 2).

In fact it was only a few lines of changes.

Using the network monitor in FireBug , my initial testing (with a 790
KB javascript file) shows that the response time is  slower with gzip
turned on (I'm guessing that it might be related to flexi-stream.)

262 KB	828ms	875ms	735ms	703ms	719ms	593ms	734ms

790 KB	625ms	359ms	672ms	328ms	610ms	641ms	594ms	

Since I'm testing with the loopback interface, there's virtually no
network overhead.

So I launch another firefox in vmware and limit the download rate of
the network interface to 150k (the most common DSL speed offered in
the states)

262 KB	1.72s	1.72s	1.64s	1.79s

790 KB	5.16s	5.21s	5.11s	5.21s

Now we're talking.  And we can't ignore the 56k line users, can't we?

262 KB	8.39s	5.07s	4.97s	5.07s

790 KB	15.36s ? point taken, I don't want to repeat this :-)


So now, the questions remain:

Should we add this to hunchentoot or make it an extension module?
(this will introduce two new dependencies to hunchentoot)

If we add this to hunchentoot, should we add a flag to turn on/off
gzip encoding? (probably yes)

And again, since there's flexi-stream overhead (my guess), should we
add a flag to control what content-type we should disable gzip
encoding? (probably wasting cpu cycle to gzip jpeg, mp3 and png, etc).

Suggestions?

-- Mac

1: http://www.cliki.net/Salza

2: http://common-lisp.net/project/gzip-stream/


(defun handle-static-file (path &optional content-type)
  "A function which acts like a Hunchentoot handler for the file
denoted by PATH.  Send a content type header corresponding to
CONTENT-TYPE or \(if that is NIL) tries to determine the content
type via the file's suffix."
  (unless (or (pathname-name path)
              (pathname-type path))
    ;; not a file
    (setf (return-code) +http-bad-request+)
    (throw 'handler-done nil))
  (unless (probe-file path)
    ;; does not exist
    (setf (return-code) +http-not-found+)
    (throw 'handler-done nil))
  (let ((time (or (file-write-date path) (get-universal-time)))
        (accept-gzip-p (search "gzip" (header-in :accept-encoding))))
    (setf (content-type) (or content-type
                             (mime-type path)
                             "application/octet-stream"))
    (handle-if-modified-since time)
    (with-open-file (file path
                     :direction :input
                     :element-type '(unsigned-byte 8)
                     :if-does-not-exist nil)
      (setf (header-out "Last-Modified") (rfc-1123-date time))
      (if accept-gzip-p
          (setf (header-out "Content-Encoding") "gzip")
          (setf (content-length) (file-length file)))
      (let ((out (send-headers)))
        (when accept-gzip-p
          (setq out (gzip-stream:make-gzip-output-stream out)))
        (loop with buf = (make-array +buffer-length+ :element-type
'(unsigned-byte 8))
              for pos = (read-sequence buf file)
              until (zerop pos)
              do (write-sequence buf out :end pos)
              (finish-output out))))))


From ocorrain at gmail.com  Sat May 26 12:16:10 2007
From: ocorrain at gmail.com (Tiarnan O'Corrain)
Date: Sat, 26 May 2007 13:16:10 +0100
Subject: [hunchentoot-devel] New release 0.11.1 (Was: Hunchentoot and
	OpenMCL)
In-Reply-To: <ud50o6dwk.fsf_-_@agharta.de>
References: <e5134fd00705250401w200b69d4l3203651478b0af4f@mail.gmail.com>
	<uwsyx5dzy.fsf@agharta.de>
	<e5134fd00705250907g1e079fb1ie324b03ca557a993@mail.gmail.com>
	<uhcq06ekq.fsf@agharta.de> <ud50o6dwk.fsf_-_@agharta.de>
Message-ID: <ea7fafc0705260516x2659f3f9q608a5b87672d3363@mail.gmail.com>

Hi--

> OK, I've made a new release which now hopefully works with the latest
> OpenMCL release.  Please check.

it seems to work fine.  Many thanks to both of you!

regards

Tiarn?n


From edi at agharta.de  Sat May 26 22:18:50 2007
From: edi at agharta.de (Edi Weitz)
Date: Sun, 27 May 2007 00:18:50 +0200
Subject: [hunchentoot-devel] gzip-encoding
In-Reply-To: <4877ae640705260324p1e925816x6929678c31d1a5b6@mail.gmail.com> (Mac
	Chan's message of "Sat, 26 May 2007 03:24:31 -0700")
References: <4877ae640705260324p1e925816x6929678c31d1a5b6@mail.gmail.com>
Message-ID: <u4plzxm7p.fsf@agharta.de>

On Sat, 26 May 2007 03:24:31 -0700, "Mac Chan" <emailmac at gmail.com> wrote:

> Using the network monitor in FireBug , my initial testing (with a
> 790 KB javascript file) shows that the response time is slower with
> gzip turned on (I'm guessing that it might be related to
> flexi-stream.)

I suppose gzip itself will also take some time, won't it?  Why do you
think flexi-streams is the culprit in this case?

> Should we add this to hunchentoot or make it an extension module?
> (this will introduce two new dependencies to hunchentoot)

I'm not against it per se, but I wouldn't want to add it just for
static files.  I think static files aren't something we should be
particularly concerned with.  If you have lots of static files and
Hunchentoot can't serve them fast enough for your purposes, let Apache
serve them, or put them behind mod_lisp and use mod_gzip.  Besides,
clients will cache Javascript files, so they'll have to read your big
Ajax library only once.

If, OTOH, you also want to allow gzip encoding for dynamic content
generated with Hunchentoot, it gets a lot more complicated,
particularly because gzip-streams are binary only.  I thought about
this for some time, and I don't see an easy and elegant way around
this - unless you want to add yet another flexi-streams layer which
would result in four (!) layers of Gray streams atop each other.

> If we add this to hunchentoot, should we add a flag to turn on/off
> gzip encoding? (probably yes)

Yes, definitely.

> And again, since there's flexi-stream overhead (my guess), should we
> add a flag to control what content-type we should disable gzip
> encoding? (probably wasting cpu cycle to gzip jpeg, mp3 and png,
> etc).

Yes.  This has nothing to do with whether flexi-streams adds overhead
or not.  It is generally a bad idea to compress formats that are
already compressed... :)

>         (accept-gzip-p (search "gzip" (header-in :accept-encoding)))

I think that's a bit too simplistic.  The header could be one of

  Accept-Encoding: x-frogzipper
  Accept-Encoding: gzip; q=0
  Accept-Encoding: *

Something like this maybe (untested):

  (defun parse-qvalue (string)
    "Checks if the string STRING is a `qvalue' according to RFC 2616 and
  returns the corresponding numeric value.  Signals an error otherwise."
    (unless (ppcre:scan "^(?:[0](?:\\.[0-9]{0,3})?|[1](?:\\.0{0,3})?)$" string)
      (error "Not a qvalue: ~S" string))
    (case (char string 0)
      (#\1 1)
      (#\0 (let ((length (length string)))
             (case length
               ((1 2) 0)
               (otherwise
                (/ (parse-integer string :start 2)
                   (case length
                     (3 10)
                     (4 100)
                     (5 1000)))))))))

  (defun accepts-gzip-p ()
    "Checks whether the user agent accepts gzip encoding according to
  the incoming headers."
    (when-let (accept-encoding-header (header-in :accept-encoding))
      (dolist (part (ppcre:split "," accept-encoding-header))
        (with-input-from-string (stream part)
          (let* ((*current-error-message* "Corrupted Accept-Encoding header:")
                 (coding (read-token stream))
                 (parameters (read-name-value-pairs stream))
                 (quality (cdr (assoc "q" parameters))))
            (when (and (member coding '("gzip" "*") :test #'string=)
                       (or (null quality)
                           (plusp (handler-case (parse-qvalue quality)
                                    (error (condition)
                                      (log-message :warn "While parsing Accept-Encoding header: ~A"
                                                   condition)
                                      0)))))
              (return-from accepts-gzip-p t)))))))

Cheers,
Edi.


From emailmac at gmail.com  Mon May 28 03:21:19 2007
From: emailmac at gmail.com (Mac Chan)
Date: Sun, 27 May 2007 20:21:19 -0700
Subject: [hunchentoot-devel] gzip-encoding
In-Reply-To: <u4plzxm7p.fsf@agharta.de>
References: <4877ae640705260324p1e925816x6929678c31d1a5b6@mail.gmail.com>
	<u4plzxm7p.fsf@agharta.de>
Message-ID: <4877ae640705272021q178c9dc3vbcbd20a78b01ac9c@mail.gmail.com>

On 5/26/07, Edi Weitz <edi at agharta.de> wrote:
> I suppose gzip itself will also take some time, won't it?  Why do you
> think flexi-streams is the culprit in this case?

Because it was convenient to blame flexi-steams ;-) (re: the upload
performance thread)

> I think static files aren't something we should be
> particularly concerned with.  If you have lots of static files and
> Hunchentoot can't serve them fast enough for your purposes, let Apache
> serve them, or put them behind mod_lisp and use mod_gzip.  Besides,
> clients will cache Javascript files, so they'll have to read your big
> Ajax library only once.

I wasn't too concerned about scalability. Like you said, if it is a
public facing high-traffic website, putting hunchentoot behind
mod-lisp would be a safer bet.

However, even in intranet application, downloading 790k verse 220k is
a huge difference in user experience.

And not to mention that you don't have to deal with apache setup and
configuration.

Imagine hacking httpd.conf and installing mods verse writing your own
mod-alias mod-rewrite in lisp, changing the rules in runtime without
restarting the web server. Which one is more fun? ;)

> >         (accept-gzip-p (search "gzip" (header-in :accept-encoding)))
>
> I think that's a bit too simplistic.  The header could be one of
>
>   Accept-Encoding: x-frogzipper
>   Accept-Encoding: gzip; q=0
>   Accept-Encoding: *

Yeah, you're right. I was just trying to do some experiments and fish
for ideas from the mailing list.

> Something like this maybe (untested):

See? I threw in a brick and got some quality code back. Not bad at all :-)

> I'm not against it per se, but I wouldn't want to add it just for
> static files.

Agreed. I don't think we should put half baked solution into
hunchentoot. For now I'll adopt it into
lsp:create-lsp-folder-dispatcher-and-handler.

Thanks,
-- Mac


From edi at agharta.de  Tue May 29 18:25:45 2007
From: edi at agharta.de (Edi Weitz)
Date: Tue, 29 May 2007 20:25:45 +0200
Subject: [hunchentoot-devel] Re: Hunchentoot REST framework
In-Reply-To: <87d50j21mp.fsf@no-log.org> (Nicolas Lamirault's message of
	"Tue, 29 May 2007 15:35:58 +0200")
References: <87odlmdanz.fsf@no-log.org> <uodlmhdr1.fsf@agharta.de>
	<87d50j21mp.fsf@no-log.org>
Message-ID: <ubqg3xz9y.fsf@agharta.de>

Hi,

On Tue, 29 May 2007 15:35:58 +0200, Nicolas Lamirault <lam at tuxfamily.org> wrote:

> i'm re-working on this framework and i've got a few problems ... 

I'd prefer if we could continue this discussion on the mailing list -
see Cc.

> i try to get parameters when a make a PUT request :
>
> $> curl -X PUT -d name=nicolas  http://localhost:8888/ht-rest/test/user/lam at foo.org

If you use curl like this, it will send the parameters as
application/x-www-form-urlencoded in the request body.  I can't see
how it would make sense to use a PUT request for this.  In a PUT
request, the request body is supposed to be the entity that is to be
stored under the request URI.

> on logs i have this :
>
> [2007-05-29 15:30:19 [INFO]] Put User
> [2007-05-29 15:30:19 [INFO]] PUT parameters NIL

Where do these log entries come from?

> and i create a function :
>
> (defun rest-put-parameter (name)
>   "Returns the value of the PUT  parameter named by the string NAME as
>   a string or NIL if there ain't no PUT parameter with this name."  
>   (hunchentoot:aux-request-value (make-symbol name)))
>
> but my function doesn't work ... 
> I think my mistake comes from i don't really understand how use the
> aux-request-value function.

Yes, it looks so.  AUX-REQUEST-VALUE is meant so you can /store/
arbitrary values associated with the request and later retrieve them.
I have no idea what REST-PUT-PARAMETER is supposed to do or what a
"PUT parameter" is.

> have u got any idea for this problem ? 

I don't understand the problem...

Did you look at CL-WEBDAV to see how it handles PUT requests as I told
you?

Cheers,
Edi.


From edi at agharta.de  Wed May 30 07:35:37 2007
From: edi at agharta.de (Edi Weitz)
Date: Wed, 30 May 2007 09:35:37 +0200
Subject: [hunchentoot-devel] Custom types for easy handler.
In-Reply-To: <697843.97803.qm@web82304.mail.mud.yahoo.com> (Timothy
	Schaeffer's message of "Fri, 25 May 2007 06:47:57 -0700 (PDT)")
References: <697843.97803.qm@web82304.mail.mud.yahoo.com>
Message-ID: <ubqg23gs6.fsf@agharta.de>

Hi,

sorry for the delay.

On Fri, 25 May 2007 06:47:57 -0700 (PDT), Timothy Schaeffer <tschaef at sbcglobal.net> wrote:

> I propose that the types for easy-handlers be extensible by the
> users.  I have pieces of markup which are used throughout our site
> which collect information from several fields into a class (in our
> case tied to a database with clsql).  The names of the fields are
> related, but diffierent from the lists, arrays and hashes of the
> easy-handlers, Dates and addresses are two good examples, but there
> are others.  I would like to be able to teach the easy handler to
> collect these for me and pass them as parameters.  This cannot be
> done with functions as the :parameter-type because the functions
> passed as :parameter-type do not take the parameter name.

I don't really understand what you're trying to do that can't be done
with REAL-NAME and a function designator for PARAMETER-TYPE.  Maybe
you can provide an example?

I'd say that if it can't be done, then your task is probably too
complicated for an "easy" handler, but maybe I'm missing something.
The idea of DEFINE-EASY-HANDLER is that it is a convenience macro for
90% of the handlers one usually writes - the mundane ones.  It was not
intended as a general purpose tool for every conceivable Hunchentoot
handler on Earth.

> BTW: why the checks for null CDDRs and CDDDDRs in compute-parameter?
> Is this just nice, or are they essential?

It is there to check for syntax errors.

> Hunchentoot is a pleasure to work with!

That's good to know... :)

Cheers,
Edi.