From lispercat at gmail.com  Tue May  5 23:50:30 2009
From: lispercat at gmail.com (Andrei Stebakov)
Date: Tue, 5 May 2009 19:50:30 -0400
Subject: [hunchentoot-devel] Socket errors during requests
Message-ID: <affe56e00905051650w4a983aefg7559747b644fe457@mail.gmail.com>

My log is full of messages like:
[2009-05-05 19:29:29 [ERROR]] Error while processing connection: I/O timeout
reading #<SB-SYS:FD-STREAM for "a socket" {D0CDBA9}>

If I trap the error stack it's like this:

0: (SB-DEBUG::MAP-BACKTRACE #<CLOSURE (LAMBDA #) {CFFA47D}>)[:EXTERNAL]
1: (BACKTRACE 536870911 #<SB-IMPL::STRING-OUTPUT-STREAM {CFB5DA1}>)
2: (TRIVIAL-BACKTRACE:PRINT-BACKTRACE-TO-STREAM
   #<SB-IMPL::STRING-OUTPUT-STREAM {CFB5DA1}>)
3: (TRIVIAL-BACKTRACE:PRINT-BACKTRACE 0)[:EXTERNAL]
4: (MY-API::MY-MESSAGE-LOGGER
   :ERROR
   "Error while processing connection: ~A"
   #<SB-SYS:IO-TIMEOUT {CF67F81}>)
5: ((FLET #:LAMBDA121) #<SB-SYS:IO-TIMEOUT {CF67F81}>)
6: (SIGNAL #<SB-SYS:IO-TIMEOUT {CF67F81}>)[:EXTERNAL]
7: (ERROR SB-SYS:IO-TIMEOUT)[:EXTERNAL]
8: (SB-IMPL::SIGNAL-TIMEOUT SB-SYS:IO-TIMEOUT)[:EXTERNAL]
9: (SB-IMPL::REFILL-INPUT-BUFFER #<SB-SYS:FD-STREAM for "a socket"
{C3DEF69}>)
10: (SB-IMPL::INPUT-UNSIGNED-8BIT-BYTE
    #<SB-SYS:FD-STREAM for "a socket" {C3DEF69}>
    NIL
    NIL)
11: (CHUNGA:READ-CHAR* #<SB-SYS:FD-STREAM for "a socket" {C3DEF69}> NIL NIL)
12: (CHUNGA:READ-LINE* #<SB-SYS:FD-STREAM for "a socket" {C3DEF69}> NIL)
13: (HUNCHENTOOT::READ-INITIAL-REQUEST-LINE
    #<SB-SYS:FD-STREAM for "a socket" {C3DEF69}>)
14: (HUNCHENTOOT::GET-REQUEST-DATA #<SB-SYS:FD-STREAM for "a socket"
{C3DEF69}>)
15: ((SB-PCL::FAST-METHOD HUNCHENTOOT:PROCESS-CONNECTION
     (HUNCHENTOOT:ACCEPTOR T))
    #<unavailable argument>
    #<unavailable argument>
    #<MY-API::MY-ACCEPTOR (host *, port 3003)>
    #<USOCKET:STREAM-USOCKET {C3DFF69}>)
16: ((SB-PCL::FAST-METHOD HUNCHENTOOT:PROCESS-CONNECTION :AROUND
     (HUNCHENTOOT:ACCEPTOR T))
    #<unavailable argument>
    #S(SB-PCL::FAST-METHOD-CALL
       :FUNCTION #<FUNCTION #>
       :PV NIL
       :NEXT-METHOD-CALL NIL
       :ARG-INFO (2))
    #<MY-API::MY-ACCEPTOR (host *, port 3003)>
    #<USOCKET:STREAM-USOCKET {C3DFF69}>)
17: ((FLET #:WITHOUT-INTERRUPTS-BODY-[BLOCK353]358))
18: ((FLET SB-THREAD::WITH-MUTEX-THUNK))
19: ((FLET #:WITHOUT-INTERRUPTS-BODY-[CALL-WITH-MUTEX]267))
20: (SB-THREAD::CALL-WITH-MUTEX
    #<CLOSURE (FLET SB-THREAD::WITH-MUTEX-THUNK) {B6D20245}>
    #S(SB-THREAD:MUTEX
       :NAME "thread result lock"
       :%OWNER #<SB-THREAD:THREAD "Hunchentoot worker (client:
127.0.0.1:44453)" RUNNING {C436EA9}>
       :STATE 1)
    #<SB-THREAD:THREAD "Hunchentoot worker (client: 127.0.0.1:44453)"
RUNNING {C436EA9}>

What could be the reason for the errors?

Thank you,
Andrei
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20090505/4167d01f/attachment.html>

From hans.huebner at gmail.com  Wed May  6 04:00:19 2009
From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Wed, 6 May 2009 06:00:19 +0200
Subject: [hunchentoot-devel] Socket errors during requests
In-Reply-To: <affe56e00905051650w4a983aefg7559747b644fe457@mail.gmail.com>
References: <affe56e00905051650w4a983aefg7559747b644fe457@mail.gmail.com>
Message-ID: <fd2982320905052100l5017f845g136d9179d8a5c333@mail.gmail.com>

On Wed, May 6, 2009 at 01:50, Andrei Stebakov <lispercat at gmail.com> wrote:
> My log is full of messages like:
> [2009-05-05 19:29:29 [ERROR]] Error while processing connection: I/O timeout
> reading #<SB-SYS:FD-STREAM for "a socket" {D0CDBA9}>
> What could be the reason for the errors?

These messages are (wrongly) generated by Hunchentoot when an incoming
HTTP connection times out.  This is a normal operating condition and
no error should be generated.  It is safe to ignore the log entries.
Are you running a recent version of Hunchentoot?  I thought that I
have fixed this problem a while ago.

-Hans



From lispercat at gmail.com  Wed May  6 14:21:18 2009
From: lispercat at gmail.com (Andrei Stebakov)
Date: Wed, 6 May 2009 10:21:18 -0400
Subject: [hunchentoot-devel] Socket errors during requests
In-Reply-To: <fd2982320905052100l5017f845g136d9179d8a5c333@mail.gmail.com>
References: <affe56e00905051650w4a983aefg7559747b644fe457@mail.gmail.com>
	<fd2982320905052100l5017f845g136d9179d8a5c333@mail.gmail.com>
Message-ID: <affe56e00905060721p23fd2a80p2fef81f69ab2410e@mail.gmail.com>

Yes, I am running Hunchentoot 1.0 which I downloaded from
http://weitz.de/files/hunchentoot.tar.gz
Where can I get the newer version with the fixed timeout error?

Thank you,
Andrei

On Wed, May 6, 2009 at 12:00 AM, Hans H?bner <hans.huebner at gmail.com> wrote:

> On Wed, May 6, 2009 at 01:50, Andrei Stebakov <lispercat at gmail.com> wrote:
> > My log is full of messages like:
> > [2009-05-05 19:29:29 [ERROR]] Error while processing connection: I/O
> timeout
> > reading #<SB-SYS:FD-STREAM for "a socket" {D0CDBA9}>
> > What could be the reason for the errors?
>
> These messages are (wrongly) generated by Hunchentoot when an incoming
> HTTP connection times out.  This is a normal operating condition and
> no error should be generated.  It is safe to ignore the log entries.
> Are you running a recent version of Hunchentoot?  I thought that I
> have fixed this problem a while ago.
>
> -Hans
>
> _______________________________________________
> 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/20090506/1dd576c6/attachment.html>

From ocorrain at gmail.com  Thu May  7 11:05:18 2009
From: ocorrain at gmail.com (Tiarnan O'Corrain)
Date: Thu, 7 May 2009 12:05:18 +0100
Subject: [hunchentoot-devel] redirect problems
Message-ID: <ea7fafc0905070405h7cbed33h1c6ec212a3558303@mail.gmail.com>

Hi--

I have a login form on the front page of a site that uses (say) /login.html
as its 'action'.  Login.html just looks at the post parameters, tries to log
the user in, and redirects to the front page, which should then display user
specific information.

However, the front page displays the old login form, and requires a refresh
to pick up the new information.

Ditto with logout, which shows the user information until the page is
refreshed.

I'm using hunchentoot:redirect with the URL, and can't figure out why this
isn't working.

Any ideas?

thanks

Tiarnan


-- 
difficile est saturam non scribere
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20090507/e8521960/attachment.html>

From larry at theclapp.org  Thu May  7 16:33:32 2009
From: larry at theclapp.org (Larry Clapp)
Date: Thu, 7 May 2009 12:33:32 -0400
Subject: [hunchentoot-devel] redirect problems
In-Reply-To: <ea7fafc0905070405h7cbed33h1c6ec212a3558303@mail.gmail.com>
References: <ea7fafc0905070405h7cbed33h1c6ec212a3558303@mail.gmail.com>
Message-ID: <20090507163332.GB29797@cupid.theclapp.org>

On Thu, May 07, 2009 at 12:05:18PM +0100, Tiarnan O'Corrain wrote:
> I have a login form on the front page of a site that uses (say) /login.html
> as its 'action'.  Login.html just looks at the post parameters, tries to log
> the user in, and redirects to the front page, which should then display user
> specific information.
> 
> However, the front page displays the old login form, and requires a refresh
> to pick up the new information.
> 
> Ditto with logout, which shows the user information until the page is
> refreshed.
> 
> I'm using hunchentoot:redirect with the URL, and can't figure out why this
> isn't working.

I *think* I encountered a similar problem with submitting a form
multiple times when reloading the page.  Try this:
http://stackoverflow.com/questions/665399/how-do-i-stop-the-back-and-refresh-buttons-from-resubmitting-my-form;
see also this: http://en.wikipedia.org/wiki/Post/Redirect/Get, and the
various external links there.

HTH.

-- L




From download at hpc.unm.edu  Mon May 18 17:03:54 2009
From: download at hpc.unm.edu (Jim Prewett)
Date: Mon, 18 May 2009 11:03:54 -0600 (MDT)
Subject: [hunchentoot-devel] Webpage documentation for REDIRECT function
Message-ID: <Pine.LNX.4.62.0905181100170.30237@trucha01.hpc.unm.edu>


Hello,

I was looking at the Hunchentoot webpage documentation for the REDIRECT 
function and noticed that it lacked information about what the 
ADD-SESSION-ID keyword argument does.  This information is available in 
the documentation string for the function (which says "Adds a session ID 
if ADD-SESSION-ID is true.").

Whaddya think about adding that to the webpage as well?

Jim

James E. Prewett                    Jim at Prewett.org download at hpc.unm.edu 
Systems Team Leader           LoGS: http://www.hpc.unm.edu/~download/LoGS/ 
Designated Security Officer         OpenPGP key: pub 1024D/31816D93    
HPC Systems Engineer III   UNM HPC  505.277.8210



From rklinda at gmail.com  Wed May 20 15:08:25 2009
From: rklinda at gmail.com (Richard KLINDA)
Date: Wed, 20 May 2009 17:08:25 +0200
Subject: [hunchentoot-devel] redirect doesn't honor
	*rewrite-for-session-urls*
Message-ID: <87vdnvvml2.fsf@gmail.com>

Hello, even with *rewrite-for-session-urls* set to nil, the redirect
function puts the session ID into the URL by calling
add-cookie-value-to-url (under some circumstances).  Is this a bug, or
am I missing something?

Thanks, 
Richard



From hrapof at common-lisp.ru  Thu May 21 12:10:34 2009
From: hrapof at common-lisp.ru (Dmitri Hrapof)
Date: Thu, 21 May 2009 12:10:34 +0000 (UTC)
Subject: [hunchentoot-devel] *supports-threads-p*
Message-ID: <loom.20090521T120538-46@post.gmane.org>

Hello!

If I load Hunchentoot 1.0.0 into ClozureCL, CCL says that *supports-threads-p*
is undefined, would you like to use bt:*supports-threads-p* instead?

The reason, it seems, is that CCL doesn't like symbol-macro *supports-threads-p*
being defined in the same file it's being used. If I move it into e.g.
compat.lisp, everything is fine.

Cheers,
Dmitri




From hrapof at common-lisp.ru  Thu May 21 13:29:33 2009
From: hrapof at common-lisp.ru (Dmitri Hrapof)
Date: Thu, 21 May 2009 13:29:33 +0000 (UTC)
Subject: [hunchentoot-devel] asterisk
Message-ID: <loom.20090521T132204-521@post.gmane.org>

And while I'm at it:
why, oh why have you added "*" to those methods? To make people recheck their
code's compatibility with new Hunchentoot?

BTW, I like the idea of easy-handlers very much. I've been making similar macros
for quite a while, and I wonder: do you plan to add to CL-WHO some machinery to
reuse these "function arguments"? I mean, often (at least for me) web page
contains a form with action pointing to the same page, and it's rather boring to
write (:input :type "text" :name "arg1" :value arg1) etc. Again, I have some
macros for that, but rather unpolished.




From sky at viridian-project.de  Thu May 21 13:40:15 2009
From: sky at viridian-project.de (Leslie P. Polzer)
Date: Thu, 21 May 2009 15:40:15 +0200 (CEST)
Subject: [hunchentoot-devel] asterisk
In-Reply-To: <loom.20090521T132204-521@post.gmane.org>
References: <loom.20090521T132204-521@post.gmane.org>
Message-ID: <2f37290cd665c756f88150e8fdd490b9.squirrel@mail.stardawn.org>


Dmitri Hrapof wrote:

> why, oh why have you added "*" to those methods? To make people recheck their
> code's compatibility with new Hunchentoot?

To discern them from the underlying accessors. Every function with the * suffix
is a convenience interface.

  Leslie

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




From hrapof at common-lisp.ru  Thu May 21 13:56:37 2009
From: hrapof at common-lisp.ru (Dmitri Hrapof)
Date: Thu, 21 May 2009 13:56:37 +0000 (UTC)
Subject: [hunchentoot-devel] asterisk
References: <loom.20090521T132204-521@post.gmane.org>
	<2f37290cd665c756f88150e8fdd490b9.squirrel@mail.stardawn.org>
Message-ID: <loom.20090521T134928-415@post.gmane.org>

Leslie P. Polzer <sky <at> viridian-project.de> writes:

> To discern them from the underlying accessors. 
> Every function with the * suffix
> is a convenience interface.

I understand that, but take, for example
(cookie-in name &optional request)
where request defaults to *REQUEST*.
I think request-uri* could be a default method 
for the generic function request-uri.

Sincerely yours,
Dmitri




From sky at viridian-project.de  Thu May 21 14:01:33 2009
From: sky at viridian-project.de (Leslie P. Polzer)
Date: Thu, 21 May 2009 16:01:33 +0200 (CEST)
Subject: [hunchentoot-devel] asterisk
In-Reply-To: <loom.20090521T134928-415@post.gmane.org>
References: <loom.20090521T132204-521@post.gmane.org>
	<2f37290cd665c756f88150e8fdd490b9.squirrel@mail.stardawn.org>
	<loom.20090521T134928-415@post.gmane.org>
Message-ID: <35eb7ebf5dc65eea2901cc37bcc24174.squirrel@mail.stardawn.org>


Dmitri Hrapof wrote:

> I understand that, but take, for example
> (cookie-in name &optional request)
> where request defaults to *REQUEST*.

COOKIE-IN doesn't have the * suffix because it doesn't
conflict with an accessor name.


> I think request-uri* could be a default method
> for the generic function request-uri.

I don't get what you're aiming for, but surely
REQUEST-URI* can never be a method for a generic
function named REQUEST-URI (lest you apply some
serious MOP hackery maybe).

  Leslie

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




From edi at agharta.de  Thu May 21 14:08:15 2009
From: edi at agharta.de (Edi Weitz)
Date: Thu, 21 May 2009 16:08:15 +0200
Subject: [hunchentoot-devel] Webpage documentation for REDIRECT function
In-Reply-To: <Pine.LNX.4.62.0905181100170.30237@trucha01.hpc.unm.edu>
References: <Pine.LNX.4.62.0905181100170.30237@trucha01.hpc.unm.edu>
Message-ID: <b56421a00905210708y3cdd2051i6f9bf68aa12afcf9@mail.gmail.com>

On Mon, May 18, 2009 at 7:03 PM, Jim Prewett <download at hpc.unm.edu> wrote:

> I was looking at the Hunchentoot webpage documentation for the REDIRECT
> function and noticed that it lacked information about what the
> ADD-SESSION-ID keyword argument does. ?This information is available in
> the documentation string for the function (which says "Adds a session ID
> if ADD-SESSION-ID is true.").
>
> Whaddya think about adding that to the webpage as well?

Yes, that should be added.

Thanks,
Edi.



From edi at agharta.de  Thu May 21 14:07:41 2009
From: edi at agharta.de (Edi Weitz)
Date: Thu, 21 May 2009 16:07:41 +0200
Subject: [hunchentoot-devel] redirect doesn't honor
	*rewrite-for-session-urls*
In-Reply-To: <87vdnvvml2.fsf@gmail.com>
References: <87vdnvvml2.fsf@gmail.com>
Message-ID: <b56421a00905210707l6770f971pa6f087697eb16e05@mail.gmail.com>

On Wed, May 20, 2009 at 5:08 PM, Richard KLINDA <rklinda at gmail.com> wrote:
> Hello, even with *rewrite-for-session-urls* set to nil, the redirect
> function puts the session ID into the URL by calling
> add-cookie-value-to-url (under some circumstances). ?Is this a bug, or
> am I missing something?

Yes, *REWRITE-FOR-SESSION-URLS* controls whether HTML pages output by
Hunchentoot should be rewritten.  REDIRECT doesn't write HTML pages,
it just sends headers.  Use the :ADD-SESSION-ID keyword argument if
you don't want the session ID to be added.

Edi.



From hrapof at common-lisp.ru  Thu May 21 14:22:21 2009
From: hrapof at common-lisp.ru (Dmitri Hrapof)
Date: Thu, 21 May 2009 14:22:21 +0000 (UTC)
Subject: [hunchentoot-devel] asterisk
References: <loom.20090521T132204-521@post.gmane.org>
	<2f37290cd665c756f88150e8fdd490b9.squirrel@mail.stardawn.org>
	<loom.20090521T134928-415@post.gmane.org>
	<35eb7ebf5dc65eea2901cc37bcc24174.squirrel@mail.stardawn.org>
Message-ID: <loom.20090521T140949-247@post.gmane.org>

Leslie P. Polzer <sky <at> viridian-project.de> writes:

> COOKIE-IN doesn't have the * suffix because it doesn't
> conflict with an accessor name.

I understand that too ;)

> I don't get what you're aiming for, but surely
> REQUEST-URI* can never be a method for a generic
> function named REQUEST-URI (lest you apply some
> serious MOP hackery maybe).

I meant:

why not
instead of REQUEST-URI*

use something like:

(defclass request ()
 ((uri)))
(defgeneric request-uri (&optional req))
(defmethod request-uri (&optional (req request))
 (when (null req) ...

though maybe sacrificing backwards-compatibility 
is better than writing all that :)








From hans.huebner at gmail.com  Thu May 21 14:45:46 2009
From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Thu, 21 May 2009 16:45:46 +0200
Subject: [hunchentoot-devel] *supports-threads-p*
In-Reply-To: <loom.20090521T120538-46@post.gmane.org>
References: <loom.20090521T120538-46@post.gmane.org>
Message-ID: <fd2982320905210745i6357e62dq8d15e48be3ba8e83@mail.gmail.com>

On Thu, May 21, 2009 at 14:10, Dmitri Hrapof <hrapof at common-lisp.ru> wrote:

> If I load Hunchentoot 1.0.0 into ClozureCL, CCL says that *supports-threads-p*
> is undefined, would you like to use bt:*supports-threads-p* instead?

What version of CCL are you using?  We use Hunchentoot on CCL
intensively and do not see that problem, so it might be related to
your CCL version (either too old or too new).  Can you supply us with
the output of (lisp-implementation-version), please?

Thanks,
-Hans



From edi at agharta.de  Thu May 21 15:08:44 2009
From: edi at agharta.de (Edi Weitz)
Date: Thu, 21 May 2009 17:08:44 +0200
Subject: [hunchentoot-devel] Socket errors during requests
In-Reply-To: <affe56e00905060721p23fd2a80p2fef81f69ab2410e@mail.gmail.com>
References: <affe56e00905051650w4a983aefg7559747b644fe457@mail.gmail.com>
	<fd2982320905052100l5017f845g136d9179d8a5c333@mail.gmail.com>
	<affe56e00905060721p23fd2a80p2fef81f69ab2410e@mail.gmail.com>
Message-ID: <b56421a00905210808rcacf53fk7762676b5d754e2f@mail.gmail.com>

On Wed, May 6, 2009 at 4:21 PM, Andrei Stebakov <lispercat at gmail.com> wrote:
> Yes, I am running Hunchentoot 1.0 which I downloaded from
> http://weitz.de/files/hunchentoot.tar.gz
> Where can I get the newer version with the fixed timeout error?

Sorry for the late reply.  I think Hans was actually referring to the
latest release version.  Failing that, you could try the dev version
from bknr.net and see if it makes a difference.

Edi.



From sky at viridian-project.de  Thu May 21 15:18:56 2009
From: sky at viridian-project.de (Leslie P. Polzer)
Date: Thu, 21 May 2009 17:18:56 +0200 (CEST)
Subject: [hunchentoot-devel] asterisk
In-Reply-To: <loom.20090521T140949-247@post.gmane.org>
References: <loom.20090521T132204-521@post.gmane.org>
	<2f37290cd665c756f88150e8fdd490b9.squirrel@mail.stardawn.org>
	<loom.20090521T134928-415@post.gmane.org>
	<35eb7ebf5dc65eea2901cc37bcc24174.squirrel@mail.stardawn.org>
	<loom.20090521T140949-247@post.gmane.org>
Message-ID: <267fe94942be1de4a3e6bd07de683847.squirrel@mail.stardawn.org>


Dmitri Hrapof wrote:

> why not
> instead of REQUEST-URI*
>
> use something like:
>
> (defclass request ()
>  ((uri)))
> (defgeneric request-uri (&optional req))
> (defmethod request-uri (&optional (req request))
>  (when (null req) ...
>
> though maybe sacrificing backwards-compatibility
> is better than writing all that :)

You would seriously subvert the essential meaning of methods,
i.e. being able to dispatch on their arguments.

How would you be able to support a custom subclass of
REQUEST wishing to specialize REQUEST-URI (and all
the other functions) then?

  Leslie

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




From marko.kocic at gmail.com  Thu May 21 14:57:30 2009
From: marko.kocic at gmail.com (=?UTF-8?B?TWFya28gS29jacSH?=)
Date: Thu, 21 May 2009 16:57:30 +0200
Subject: [hunchentoot-devel] *supports-threads-p*
In-Reply-To: <fd2982320905210745i6357e62dq8d15e48be3ba8e83@mail.gmail.com>
References: <loom.20090521T120538-46@post.gmane.org>
	<fd2982320905210745i6357e62dq8d15e48be3ba8e83@mail.gmail.com>
Message-ID: <9238e8de0905210757w21b7bf79va70f6cf148eae3e@mail.gmail.com>

Ecl also has problems with this, so it might be worth handling.

2009/5/21 Hans H?bner <hans.huebner at gmail.com>:
> On Thu, May 21, 2009 at 14:10, Dmitri Hrapof <hrapof at common-lisp.ru> wrote:
>
>> If I load Hunchentoot 1.0.0 into ClozureCL, CCL says that *supports-threads-p*
>> is undefined, would you like to use bt:*supports-threads-p* instead?
>
> What version of CCL are you using? ?We use Hunchentoot on CCL
> intensively and do not see that problem, so it might be related to
> your CCL version (either too old or too new). ?Can you supply us with
> the output of (lisp-implementation-version), please?
>
> Thanks,
> -Hans
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>



From edi at agharta.de  Thu May 21 16:06:45 2009
From: edi at agharta.de (Edi Weitz)
Date: Thu, 21 May 2009 18:06:45 +0200
Subject: [hunchentoot-devel] asterisk
In-Reply-To: <267fe94942be1de4a3e6bd07de683847.squirrel@mail.stardawn.org>
References: <loom.20090521T132204-521@post.gmane.org>
	<2f37290cd665c756f88150e8fdd490b9.squirrel@mail.stardawn.org>
	<loom.20090521T134928-415@post.gmane.org>
	<35eb7ebf5dc65eea2901cc37bcc24174.squirrel@mail.stardawn.org>
	<loom.20090521T140949-247@post.gmane.org>
	<267fe94942be1de4a3e6bd07de683847.squirrel@mail.stardawn.org>
Message-ID: <b56421a00905210906i29a965e7l92583fc044d0295e@mail.gmail.com>

On Thu, May 21, 2009 at 5:18 PM, Leslie P. Polzer
<sky at viridian-project.de> wrote:

> You would seriously subvert the essential meaning of methods,
> i.e. being able to dispatch on their arguments.

Yep, exactly.  That was the reason we didn't do it this way.



From edi at agharta.de  Thu May 21 16:10:04 2009
From: edi at agharta.de (Edi Weitz)
Date: Thu, 21 May 2009 18:10:04 +0200
Subject: [hunchentoot-devel] Socket errors during requests
In-Reply-To: <affe56e00905210840q39cbe8f8yf89b0b6e5de90c80@mail.gmail.com>
References: <affe56e00905051650w4a983aefg7559747b644fe457@mail.gmail.com>
	<fd2982320905052100l5017f845g136d9179d8a5c333@mail.gmail.com>
	<affe56e00905060721p23fd2a80p2fef81f69ab2410e@mail.gmail.com>
	<b56421a00905210808rcacf53fk7762676b5d754e2f@mail.gmail.com>
	<affe56e00905210840q39cbe8f8yf89b0b6e5de90c80@mail.gmail.com>
Message-ID: <b56421a00905210910n564c8c9fy43d52f2ae91bea4b@mail.gmail.com>

On Thu, May 21, 2009 at 5:40 PM, Andrei Stebakov <lispercat at gmail.com> wrote:

> What's the link to dev version of hunchentoot (I don't know how to find it
> on bknr.net)?

Start here

  http://bknr.net/trac/browser

and then either look at "trunk/thirdware" or at "ediware".

> Could you be so kind to put instructions how to get the dev version on your
> main page for Hunchentoot at http://www.weitz.de/hunchentoot/?

I'm reluctant to do that.  I think that someone who wants to work with
the "cutting edge" version should also be prepared to subscribe to the
dev mailing list where this link has been mentioned a couple of times.
 I don't really want to encourage unsuspecting users to use the dev
version.

Edi.



From lispercat at gmail.com  Thu May 21 15:40:54 2009
From: lispercat at gmail.com (Andrei Stebakov)
Date: Thu, 21 May 2009 11:40:54 -0400
Subject: [hunchentoot-devel] Socket errors during requests
In-Reply-To: <b56421a00905210808rcacf53fk7762676b5d754e2f@mail.gmail.com>
References: <affe56e00905051650w4a983aefg7559747b644fe457@mail.gmail.com>
	<fd2982320905052100l5017f845g136d9179d8a5c333@mail.gmail.com>
	<affe56e00905060721p23fd2a80p2fef81f69ab2410e@mail.gmail.com>
	<b56421a00905210808rcacf53fk7762676b5d754e2f@mail.gmail.com>
Message-ID: <affe56e00905210840q39cbe8f8yf89b0b6e5de90c80@mail.gmail.com>

Hi Edi

What's the link to dev version of hunchentoot (I don't know how to find it
on bknr.net)?
Could you be so kind to put instructions how to get the dev version on your
main page for Hunchentoot at http://www.weitz.de/hunchentoot/?

Thank you,
Andrew

On Thu, May 21, 2009 at 11:08 AM, Edi Weitz <edi at agharta.de> wrote:

> On Wed, May 6, 2009 at 4:21 PM, Andrei Stebakov <lispercat at gmail.com>
> wrote:
> > Yes, I am running Hunchentoot 1.0 which I downloaded from
> > http://weitz.de/files/hunchentoot.tar.gz
> > Where can I get the newer version with the fixed timeout error?
>
> Sorry for the late reply.  I think Hans was actually referring to the
> latest release version.  Failing that, you could try the dev version
> from bknr.net and see if it makes a difference.
>
> Edi.
>
> _______________________________________________
> 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/20090521/9256fc0a/attachment.html>

From hrapof at common-lisp.ru  Thu May 21 19:19:04 2009
From: hrapof at common-lisp.ru (Dmitri Hrapof)
Date: Thu, 21 May 2009 19:19:04 +0000 (UTC)
Subject: [hunchentoot-devel] *supports-threads-p*
References: <loom.20090521T120538-46@post.gmane.org>
	<fd2982320905210745i6357e62dq8d15e48be3ba8e83@mail.gmail.com>
Message-ID: <loom.20090521T191701-180@post.gmane.org>

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

> the output of (lisp-implementation-version), please?

"Version 1.2-r10892M  (FreebsdX8664)"
"Version 1.2-r11583M  (LinuxPPC32)"

It seems I should upgrade...




From hrapof at common-lisp.ru  Thu May 21 19:36:59 2009
From: hrapof at common-lisp.ru (Dmitri Hrapof)
Date: Thu, 21 May 2009 19:36:59 +0000 (UTC)
Subject: [hunchentoot-devel] asterisk
References: <loom.20090521T132204-521@post.gmane.org>
	<2f37290cd665c756f88150e8fdd490b9.squirrel@mail.stardawn.org>
	<loom.20090521T134928-415@post.gmane.org>
	<35eb7ebf5dc65eea2901cc37bcc24174.squirrel@mail.stardawn.org>
	<loom.20090521T140949-247@post.gmane.org>
	<267fe94942be1de4a3e6bd07de683847.squirrel@mail.stardawn.org>
Message-ID: <loom.20090521T192909-537@post.gmane.org>

Yes, it turns out (defmethod request-uri (&optional (req a)) doesn't work as I
thought. Should make some new hrARpC dialect ;)

Thank you!





From lispercat at gmail.com  Thu May 21 19:44:37 2009
From: lispercat at gmail.com (Andrei Stebakov)
Date: Thu, 21 May 2009 15:44:37 -0400
Subject: [hunchentoot-devel] Socket errors during requests
In-Reply-To: <b56421a00905210910n564c8c9fy43d52f2ae91bea4b@mail.gmail.com>
References: <affe56e00905051650w4a983aefg7559747b644fe457@mail.gmail.com>
	<fd2982320905052100l5017f845g136d9179d8a5c333@mail.gmail.com>
	<affe56e00905060721p23fd2a80p2fef81f69ab2410e@mail.gmail.com>
	<b56421a00905210808rcacf53fk7762676b5d754e2f@mail.gmail.com>
	<affe56e00905210840q39cbe8f8yf89b0b6e5de90c80@mail.gmail.com>
	<b56421a00905210910n564c8c9fy43d52f2ae91bea4b@mail.gmail.com>
Message-ID: <affe56e00905211244q93b6da1h7471b803b0cfb917@mail.gmail.com>

I tried the development version from svn://
bknr.net/svn/trunk/thirdparty/hunchentoot
Actually, read-initial-request-line has the condition:

    (handler-case
        (let ((*current-error-message* "While reading initial request
line:"))
          (with-mapped-conditions ()
            (read-line* stream)))
      ((or end-of-file
           #-:lispworks usocket:timeout-error) ()
        nil))))

Only it doesn't cover the sbcl type error that I have. If I add #+sbcl
sb-sys:io-timeout to the handler-case error list, the error is suppressed,
but I am not sure it it's the proper fix for everyone. Basically the
function that works for me is following:
(defun read-initial-request-line (stream)
  "Reads and returns the initial HTTP request line, catching permitted
errors
and handling *BREAK-EVEN-WHILE-READING-REQUEST-TYPE-P*.  If no request could
be read, returns NIL.  At this point, both an end-of-file as well as a
timeout condition are normal.  end-of-file will occur when the client has
decided to not send another request but close the connection.  A timeout
indicates that the connection timeout established by Hunchentoot has expired
and we do not want to wait for another request any longer."
  (let ((*break-on-signals* (and *break-even-while-reading-request-type-p*
                                 *break-on-signals*)))
    (handler-case
        (let ((*current-error-message* "While reading initial request
line:"))
          (with-mapped-conditions ()
            (read-line* stream)))
      ((or end-of-file
        #-:lispworks usocket:timeout-error
        #+sbcl sb-sys:io-timeout) ()
        nil))))


Thank you,
Andrei

On Thu, May 21, 2009 at 12:10 PM, Edi Weitz <edi at agharta.de> wrote:

> On Thu, May 21, 2009 at 5:40 PM, Andrei Stebakov <lispercat at gmail.com>
> wrote:
>
> > What's the link to dev version of hunchentoot (I don't know how to find
> it
> > on bknr.net)?
>
> Start here
>
>  http://bknr.net/trac/browser
>
> and then either look at "trunk/thirdware" or at "ediware".
>
> > Could you be so kind to put instructions how to get the dev version on
> your
> > main page for Hunchentoot at http://www.weitz.de/hunchentoot/?
>
> I'm reluctant to do that.  I think that someone who wants to work with
> the "cutting edge" version should also be prepared to subscribe to the
> dev mailing list where this link has been mentioned a couple of times.
>  I don't really want to encourage unsuspecting users to use the dev
> version.
>
> Edi.
>
> _______________________________________________
> 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/20090521/ec3c8ebd/attachment.html>

From hans.huebner at gmail.com  Thu May 21 20:40:41 2009
From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Thu, 21 May 2009 22:40:41 +0200
Subject: [hunchentoot-devel] Socket errors during requests
In-Reply-To: <affe56e00905211244q93b6da1h7471b803b0cfb917@mail.gmail.com>
References: <affe56e00905051650w4a983aefg7559747b644fe457@mail.gmail.com> 
	<fd2982320905052100l5017f845g136d9179d8a5c333@mail.gmail.com> 
	<affe56e00905060721p23fd2a80p2fef81f69ab2410e@mail.gmail.com> 
	<b56421a00905210808rcacf53fk7762676b5d754e2f@mail.gmail.com> 
	<affe56e00905210840q39cbe8f8yf89b0b6e5de90c80@mail.gmail.com> 
	<b56421a00905210910n564c8c9fy43d52f2ae91bea4b@mail.gmail.com> 
	<affe56e00905211244q93b6da1h7471b803b0cfb917@mail.gmail.com>
Message-ID: <fd2982320905211340k478c3da9va766eb5d4ef7bd60@mail.gmail.com>

On Thu, May 21, 2009 at 21:44, Andrei Stebakov <lispercat at gmail.com> wrote:
> Only it doesn't cover the sbcl type error that I have. If I add #+sbcl
> sb-sys:io-timeout to the handler-case error list, the error is suppressed,

This is actually an usocket error - It should convert the
SBCL-specific condition to a portable usocket condition.  Can you try
to add (sb-sys:io-timeout . timeout-error) to +sbcl-error-map+ in
usocket/backend/sbcl.lisp and see if that cures the problem?  If it
does, I can commit a context diff that you send to the usocket
repository.

-Hans



From lispercat at gmail.com  Thu May 21 21:07:59 2009
From: lispercat at gmail.com (Andrei Stebakov)
Date: Thu, 21 May 2009 17:07:59 -0400
Subject: [hunchentoot-devel] Socket errors during requests
In-Reply-To: <fd2982320905211340k478c3da9va766eb5d4ef7bd60@mail.gmail.com>
References: <affe56e00905051650w4a983aefg7559747b644fe457@mail.gmail.com>
	<fd2982320905052100l5017f845g136d9179d8a5c333@mail.gmail.com>
	<affe56e00905060721p23fd2a80p2fef81f69ab2410e@mail.gmail.com>
	<b56421a00905210808rcacf53fk7762676b5d754e2f@mail.gmail.com>
	<affe56e00905210840q39cbe8f8yf89b0b6e5de90c80@mail.gmail.com>
	<b56421a00905210910n564c8c9fy43d52f2ae91bea4b@mail.gmail.com>
	<affe56e00905211244q93b6da1h7471b803b0cfb917@mail.gmail.com>
	<fd2982320905211340k478c3da9va766eb5d4ef7bd60@mail.gmail.com>
Message-ID: <affe56e00905211407g4d79dc5age24b9ca0186bdee8@mail.gmail.com>

Yes, it works.
Thank you,
Andrei

On Thu, May 21, 2009 at 4:40 PM, Hans H?bner <hans.huebner at gmail.com> wrote:

> On Thu, May 21, 2009 at 21:44, Andrei Stebakov <lispercat at gmail.com>
> wrote:
> > Only it doesn't cover the sbcl type error that I have. If I add #+sbcl
> > sb-sys:io-timeout to the handler-case error list, the error is
> suppressed,
>
> This is actually an usocket error - It should convert the
> SBCL-specific condition to a portable usocket condition.  Can you try
> to add (sb-sys:io-timeout . timeout-error) to +sbcl-error-map+ in
> usocket/backend/sbcl.lisp and see if that cures the problem?  If it
> does, I can commit a context diff that you send to the usocket
> repository.
>
> -Hans
>
> _______________________________________________
> 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/20090521/7c98e97e/attachment.html>

From hans.huebner at gmail.com  Thu May 21 21:11:42 2009
From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Thu, 21 May 2009 23:11:42 +0200
Subject: [hunchentoot-devel] Socket errors during requests
In-Reply-To: <affe56e00905211407g4d79dc5age24b9ca0186bdee8@mail.gmail.com>
References: <affe56e00905051650w4a983aefg7559747b644fe457@mail.gmail.com> 
	<fd2982320905052100l5017f845g136d9179d8a5c333@mail.gmail.com> 
	<affe56e00905060721p23fd2a80p2fef81f69ab2410e@mail.gmail.com> 
	<b56421a00905210808rcacf53fk7762676b5d754e2f@mail.gmail.com> 
	<affe56e00905210840q39cbe8f8yf89b0b6e5de90c80@mail.gmail.com> 
	<b56421a00905210910n564c8c9fy43d52f2ae91bea4b@mail.gmail.com> 
	<affe56e00905211244q93b6da1h7471b803b0cfb917@mail.gmail.com> 
	<fd2982320905211340k478c3da9va766eb5d4ef7bd60@mail.gmail.com> 
	<affe56e00905211407g4d79dc5age24b9ca0186bdee8@mail.gmail.com>
Message-ID: <fd2982320905211411k23d72360u24afcd42b099998a@mail.gmail.com>

On Thu, May 21, 2009 at 23:07, Andrei Stebakov <lispercat at gmail.com> wrote:
> Yes, it works.
> Thank you,

Can you send a context diff so that I can fix usocket for everyone?

Thanks,
Hans



From rklinda at gmail.com  Sat May 23 09:40:45 2009
From: rklinda at gmail.com (Richard KLINDA)
Date: Sat, 23 May 2009 11:40:45 +0200
Subject: [hunchentoot-devel] redirect doesn't honor
	*rewrite-for-session-urls*
In-Reply-To: <b56421a00905210707l6770f971pa6f087697eb16e05@mail.gmail.com>
	(Edi Weitz's message of "Thu, 21 May 2009 16:07:41 +0200")
References: <87vdnvvml2.fsf@gmail.com>
	<b56421a00905210707l6770f971pa6f087697eb16e05@mail.gmail.com>
Message-ID: <87ljooqhr6.fsf@gmail.com>

>>>>> Regarding 'Re: [hunchentoot-devel] redirect doesn't honor *rewrite-for-session-urls*'; Edi Weitz adds:


  >> Hello, even with *rewrite-for-session-urls* set to nil, the
  >> redirect function puts the session ID into the URL by calling
  >> add-cookie-value-to-url (under some circumstances). ?Is this a bug,
  >> or am I missing something?

  > Yes, *REWRITE-FOR-SESSION-URLS* controls whether HTML pages output
  > by Hunchentoot should be rewritten.  REDIRECT doesn't write HTML
  > pages, it just sends headers.  Use the :ADD-SESSION-ID keyword
  > argument if you don't want the session ID to be added.

Ahh, I understand, thank you!

Richard