From edi at agharta.de  Fri Jan  8 11:54:43 2010
From: edi at agharta.de (Edi Weitz)
Date: Fri, 8 Jan 2010 12:54:43 +0100
Subject: [hunchentoot-devel] New Hunchentoot release 1.1.0
Message-ID: <b56421a01001080354m4f6ddaf9yd055e922fbf0822c@mail.gmail.com>

As pre-announced in December, Hunchentoot 1.1.0 is now out.  Lots of
changes, see documentation.  Thanks to all who sent patches,
suggestions, or bug reports.

Happy New Year,
Edi.



From vseloved at gmail.com  Fri Jan  8 23:10:43 2010
From: vseloved at gmail.com (Vsevolod Dyomkin)
Date: Sat, 9 Jan 2010 01:10:43 +0200
Subject: [hunchentoot-devel] New Hunchentoot release 1.1.0
In-Reply-To: <b56421a01001080354m4f6ddaf9yd055e922fbf0822c@mail.gmail.com>
References: <b56421a01001080354m4f6ddaf9yd055e922fbf0822c@mail.gmail.com>
Message-ID: <89dc7c5b1001081510vaa01a59j4a95ba6bb4fa2a2e@mail.gmail.com>

Thanks for the release,
just a minor issuet: the current doc at http://weitz.de/hunchentoot seems to
not have being built properly, as it remains in XML format instead of HTML.

Best regards,
Vsevolod

On Fri, Jan 8, 2010 at 1:54 PM, Edi Weitz <edi at agharta.de> wrote:

> As pre-announced in December, Hunchentoot 1.1.0 is now out.  Lots of
> changes, see documentation.  Thanks to all who sent patches,
> suggestions, or bug reports.
>
> Happy New Year,
> Edi.
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>



-- 
vsevolod
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20100109/9e90f8e6/attachment.html>

From edi at agharta.de  Sat Jan  9 01:45:06 2010
From: edi at agharta.de (Edi Weitz)
Date: Sat, 9 Jan 2010 02:45:06 +0100
Subject: [hunchentoot-devel] New Hunchentoot release 1.1.0
In-Reply-To: <89dc7c5b1001081510vaa01a59j4a95ba6bb4fa2a2e@mail.gmail.com>
References: <b56421a01001080354m4f6ddaf9yd055e922fbf0822c@mail.gmail.com>
	<89dc7c5b1001081510vaa01a59j4a95ba6bb4fa2a2e@mail.gmail.com>
Message-ID: <b56421a01001081745r29c1bb09ge7ea8555a8039a4@mail.gmail.com>

On Sat, Jan 9, 2010 at 12:10 AM, Vsevolod Dyomkin <vseloved at gmail.com> wrote:
> Thanks for the release,
> just a minor issuet: the current doc at http://weitz.de/hunchentoot seems to
> not have being built properly, as it remains in XML format instead of HTML.

Works for me with Firefox.  Which browser are you using?



From cavandusen at gmail.com  Sat Jan  9 01:56:53 2010
From: cavandusen at gmail.com (Chris Van Dusen)
Date: Fri, 8 Jan 2010 19:56:53 -0600
Subject: [hunchentoot-devel] New Hunchentoot release 1.1.0
In-Reply-To: <b56421a01001081745r29c1bb09ge7ea8555a8039a4@mail.gmail.com>
References: <b56421a01001080354m4f6ddaf9yd055e922fbf0822c@mail.gmail.com>
	<89dc7c5b1001081510vaa01a59j4a95ba6bb4fa2a2e@mail.gmail.com>
	<b56421a01001081745r29c1bb09ge7ea8555a8039a4@mail.gmail.com>
Message-ID: <4CFEA8CD-957F-4627-8295-7AB0EF1F01C1@gmail.com>

Works in Safari.

Chris.

On Jan 8, 2010, at 7:45 PM, Edi Weitz wrote:

> On Sat, Jan 9, 2010 at 12:10 AM, Vsevolod Dyomkin <vseloved at gmail.com> wrote:
>> Thanks for the release,
>> just a minor issuet: the current doc at http://weitz.de/hunchentoot seems to
>> not have being built properly, as it remains in XML format instead of HTML.
> 
> Works for me with Firefox.  Which browser are you using?
> 
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel




From vseloved at gmail.com  Sat Jan  9 06:02:55 2010
From: vseloved at gmail.com (Vsevolod Dyomkin)
Date: Sat, 9 Jan 2010 08:02:55 +0200
Subject: [hunchentoot-devel] New Hunchentoot release 1.1.0
In-Reply-To: <b56421a01001081745r29c1bb09ge7ea8555a8039a4@mail.gmail.com>
References: <b56421a01001080354m4f6ddaf9yd055e922fbf0822c@mail.gmail.com> 
	<89dc7c5b1001081510vaa01a59j4a95ba6bb4fa2a2e@mail.gmail.com> 
	<b56421a01001081745r29c1bb09ge7ea8555a8039a4@mail.gmail.com>
Message-ID: <89dc7c5b1001082202p6c8c8b95webd7c78903755fef@mail.gmail.com>

FF 3.5
I've figured, that it's the effect of NoScript

On Sat, Jan 9, 2010 at 3:45 AM, Edi Weitz <edi at agharta.de> wrote:

> On Sat, Jan 9, 2010 at 12:10 AM, Vsevolod Dyomkin <vseloved at gmail.com>
> wrote:
> > Thanks for the release,
> > just a minor issuet: the current doc at http://weitz.de/hunchentootseems to
> > not have being built properly, as it remains in XML format instead of
> HTML.
>
> Works for me with Firefox.  Which browser are you using?
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>



-- 
vsevolod
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20100109/ca1dcfac/attachment.html>

From info at jensteich.de  Sat Jan  9 17:37:48 2010
From: info at jensteich.de (Jens Teich)
Date: Sat, 09 Jan 2010 18:37:48 +0100
Subject: [hunchentoot-devel] Problem with LW6
Message-ID: <4B48BEEC.8090306@jensteich.de>

Hunchentoot 0.15.6

when loading via asdf I get an error with LW6 where everything went 
smooth with LW5.1

[...]
; (DEFCLASS HUNCHENTOOT::SERVER)

**++++ Error in HUNCHENTOOT:START-SERVER:
   WITHOUT-PREEMPTION is used
; HUNCHENTOOT:STOP-SERVER
; HUNCHENTOOT::PROCESS-CONNECTION
; HUNCHENTOOT::PROCESS-REQUEST
;; Processing Cross Reference Information
; *** 1 error detected, no fasl file produced.
Warning: COMPILE-FILE warned while performing #<ASDF:COMPILE-OP NIL 
21DACF73> on #<ASDF:CL-SOURCE-FILE "server" 21A6D5AB>.
Warning: COMPILE-FILE failed while performing #<ASDF:COMPILE-OP NIL 
21DACF73> on #<ASDF:CL-SOURCE-FILE "server" 21A6D5AB>.
Error: erred while invoking #<ASDF:COMPILE-OP NIL 21DACF73> on 
#<ASDF:CL-SOURCE-FILE "server" 21A6D5AB>
   1 (continue) Retry performing #<ASDF:LOAD-OP NIL 21A6850F> on 
#<ASDF:CL-SOURCE-FILE "server" 21A6D5AB>.
   2 Continue, treating #<ASDF:LOAD-OP NIL 21A6850F> on 
#<ASDF:CL-SOURCE-FILE "server" 21A6D5AB> as having been successful.
   3 (abort) Return to level 0.
   4 Return to top loop level 0.

Type :b for backtrace or :c <option number> to proceed.
Type :bug-form "<subject>" for a bug report template or :? for other 
options.

CL-USER 2 : 1 > :b
Call to ERROR
Call to CLOS::METHOD-COMBINATION-TEMPLATE
Interpreted call to (METHOD ASDF:PERFORM :AROUND (ASDF:LOAD-OP 
ASDF:CL-SOURCE-FILE))
Call to CLOS::METHOD-COMBINATION-TEMPLATE
Call to (SUBFUNCTION 1 ASDF:OPERATE)
Call to ASDF:OPERATE
Call to ASDF:OOS
Interpreted call to ASDF
Call to EVAL
Call to CAPI::CAPI-TOP-LEVEL-FUNCTION
Call to CAPI::INTERACTIVE-PANE-TOP-LOOP
Call to MP::PROCESS-SG-FUNCTION

CL-USER 3 : 1 >



From ndl at ravenbrook.com  Sat Jan  9 18:20:40 2010
From: ndl at ravenbrook.com (Nick Levine)
Date: Sat, 9 Jan 2010 18:20:40 GMT
Subject: [hunchentoot-devel] Problem with LW6
In-Reply-To: <4B48BEEC.8090306@jensteich.de> (message from Jens Teich on Sat, 
	09 Jan 2010 18:37:48 +0100)
References: <4B48BEEC.8090306@jensteich.de>
Message-ID: <201001091820.o09IKeXl007779@raven.ravenbrook.com>

WITHOUT-PREEMPTION is not supported in LW 6. All calls will need
rewriting.

- nick



From edi at agharta.de  Sat Jan  9 19:48:30 2010
From: edi at agharta.de (Edi Weitz)
Date: Sat, 9 Jan 2010 20:48:30 +0100
Subject: [hunchentoot-devel] Problem with LW6
In-Reply-To: <4B48BEEC.8090306@jensteich.de>
References: <4B48BEEC.8090306@jensteich.de>
Message-ID: <b56421a01001091148s188d9748y8b1f58001a2f726d@mail.gmail.com>

You'll have to patch this yourself or try a newer version of
Hunchentoot.  Hunchentoot 1.1.0 is supposed to work with LW6 (thanks
to Nico de Jager) although I didn't get around to test it myself yet.

Edi.


On Sat, Jan 9, 2010 at 6:37 PM, Jens Teich <info at jensteich.de> wrote:
> Hunchentoot 0.15.6
>
> when loading via asdf I get an error with LW6 where everything went
> smooth with LW5.1
>
> [...]
> ; (DEFCLASS HUNCHENTOOT::SERVER)
>
> **++++ Error in HUNCHENTOOT:START-SERVER:
> ? WITHOUT-PREEMPTION is used
> ; HUNCHENTOOT:STOP-SERVER
> ; HUNCHENTOOT::PROCESS-CONNECTION
> ; HUNCHENTOOT::PROCESS-REQUEST
> ;; Processing Cross Reference Information
> ; *** 1 error detected, no fasl file produced.
> Warning: COMPILE-FILE warned while performing #<ASDF:COMPILE-OP NIL
> 21DACF73> on #<ASDF:CL-SOURCE-FILE "server" 21A6D5AB>.
> Warning: COMPILE-FILE failed while performing #<ASDF:COMPILE-OP NIL
> 21DACF73> on #<ASDF:CL-SOURCE-FILE "server" 21A6D5AB>.
> Error: erred while invoking #<ASDF:COMPILE-OP NIL 21DACF73> on
> #<ASDF:CL-SOURCE-FILE "server" 21A6D5AB>
> ? 1 (continue) Retry performing #<ASDF:LOAD-OP NIL 21A6850F> on
> #<ASDF:CL-SOURCE-FILE "server" 21A6D5AB>.
> ? 2 Continue, treating #<ASDF:LOAD-OP NIL 21A6850F> on
> #<ASDF:CL-SOURCE-FILE "server" 21A6D5AB> as having been successful.
> ? 3 (abort) Return to level 0.
> ? 4 Return to top loop level 0.
>
> Type :b for backtrace or :c <option number> to proceed.
> Type :bug-form "<subject>" for a bug report template or :? for other
> options.
>
> CL-USER 2 : 1 > :b
> Call to ERROR
> Call to CLOS::METHOD-COMBINATION-TEMPLATE
> Interpreted call to (METHOD ASDF:PERFORM :AROUND (ASDF:LOAD-OP
> ASDF:CL-SOURCE-FILE))
> Call to CLOS::METHOD-COMBINATION-TEMPLATE
> Call to (SUBFUNCTION 1 ASDF:OPERATE)
> Call to ASDF:OPERATE
> Call to ASDF:OOS
> Interpreted call to ASDF
> Call to EVAL
> Call to CAPI::CAPI-TOP-LEVEL-FUNCTION
> Call to CAPI::INTERACTIVE-PANE-TOP-LOOP
> Call to MP::PROCESS-SG-FUNCTION
>
> CL-USER 3 : 1 >
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>
>



From ndj at bitart.cc  Mon Jan 11 17:53:23 2010
From: ndj at bitart.cc (Nico de Jager)
Date: Mon, 11 Jan 2010 19:53:23 +0200
Subject: [hunchentoot-devel] Missing hunchentoot-test.asd in Hunchentoot
	1.1.0
Message-ID: <877hro8r58.fsf@galileo.bitart.cc>

Hi

The tar archive of Hunchentoot 1.1.0 on weitz.de is missing the
hunchentoot-test.asd file, which is surely by accident since the
documentation still mentions it.

Thanks for the new version!
Nico



From ndj at bitart.cc  Mon Jan 11 18:18:23 2010
From: ndj at bitart.cc (Nico de Jager)
Date: Mon, 11 Jan 2010 20:18:23 +0200
Subject: [hunchentoot-devel] New Hunchentoot release 1.1.0
In-Reply-To: <b56421a01001081745r29c1bb09ge7ea8555a8039a4@mail.gmail.com> (Edi
	Weitz's message of "Sat, 9 Jan 2010 02:45:06 +0100")
References: <b56421a01001080354m4f6ddaf9yd055e922fbf0822c@mail.gmail.com>
	<89dc7c5b1001081510vaa01a59j4a95ba6bb4fa2a2e@mail.gmail.com>
	<b56421a01001081745r29c1bb09ge7ea8555a8039a4@mail.gmail.com>
Message-ID: <873a2c8pzk.fsf@galileo.bitart.cc>

Edi Weitz <edi at agharta.de> writes:

> On Sat, Jan 9, 2010 at 12:10 AM, Vsevolod Dyomkin <vseloved at gmail.com> wrote:
>> Thanks for the release,
>> just a minor issuet: the current doc at http://weitz.de/hunchentoot seems to
>> not have being built properly, as it remains in XML format instead of HTML.
>
> Works for me with Firefox.  Which browser are you using?

w3m with a black background in Emacs, when reading a lot of on-line
documentation.

It is trivial to create an html version with xsltproc
(http://linuxcommand.org/man_pages/xsltproc1.html):

.../hunchentoot-1.1.0/doc$ xsltproc clixdoc.xsl index.xml > index.html



From edi at agharta.de  Mon Jan 11 19:37:42 2010
From: edi at agharta.de (Edi Weitz)
Date: Mon, 11 Jan 2010 20:37:42 +0100
Subject: [hunchentoot-devel] Missing hunchentoot-test.asd in Hunchentoot
	1.1.0
In-Reply-To: <877hro8r58.fsf@galileo.bitart.cc>
References: <877hro8r58.fsf@galileo.bitart.cc>
Message-ID: <b56421a01001111137j41d43097xe4b45b3cbd623f99@mail.gmail.com>

Hi Nico,

On Mon, Jan 11, 2010 at 6:53 PM, Nico de Jager <ndj at bitart.cc> wrote:

> The tar archive of Hunchentoot 1.1.0 on weitz.de is missing the
> hunchentoot-test.asd file, which is surely by accident since the
> documentation still mentions it.

The system definitions are all in one ASD file now.  Where does the
documentation mention the hunchentoot-test.asd file?  I just grepped
through the source files and couldn't find it.

Thanks,
Edi.



From ndj at bitart.cc  Mon Jan 11 20:33:40 2010
From: ndj at bitart.cc (Nico de Jager)
Date: Mon, 11 Jan 2010 22:33:40 +0200
Subject: [hunchentoot-devel] Missing hunchentoot-test.asd in Hunchentoot
	1.1.0
In-Reply-To: <b56421a01001111137j41d43097xe4b45b3cbd623f99@mail.gmail.com>
	(Edi Weitz's message of "Mon, 11 Jan 2010 20:37:42 +0100")
References: <877hro8r58.fsf@galileo.bitart.cc>
	<b56421a01001111137j41d43097xe4b45b3cbd623f99@mail.gmail.com>
Message-ID: <87ljg44c0r.fsf@galileo.bitart.cc>

Edi Weitz <edi at agharta.de> writes:

> Hi Nico,
>
> On Mon, Jan 11, 2010 at 6:53 PM, Nico de Jager <ndj at bitart.cc> wrote:
>
>> The tar archive of Hunchentoot 1.1.0 on weitz.de is missing the
>> hunchentoot-test.asd file, which is surely by accident since the
>> documentation still mentions it.
>
> The system definitions are all in one ASD file now.  Where does the
> documentation mention the hunchentoot-test.asd file?  I just grepped
> through the source files and couldn't find it.

Sorry, my mistake. I was updating my ASDF sym-links and noticed that
hunchentoot-test.asd was suddenly missing, while this line
(asdf:oos 'asdf:load-op :hunchentoot-test)
was still in the documentation, and there was no mention of the change
in the changelog. I should have tested before posting...



From martin.loetzsch at gmail.com  Thu Jan 14 16:09:54 2010
From: martin.loetzsch at gmail.com (Martin Loetzsch)
Date: Thu, 14 Jan 2010 17:09:54 +0100
Subject: [hunchentoot-devel] Hunchentoot 1.1 + HT-Ajax
Message-ID: <A0C96A70-D09A-41C3-A7C1-9F17D2FBBFAA@gmail.com>

Dear all,

recent changes in Hunchentoot prevented ht-ajax from compiling. This  
is easy to fix locally, but I don't know what to do so that the  
version on this site also works:
http://common-lisp.net/projecs/ht-ajax/

This is bad because a library of mine ( http://martin-loetzsch.de/ 
gtfl ) uses both hunchentoot and ht-ajax and people who try to install  
it will asdf:install with fail.


Do you know who currently feels responsible for ht-ajax?

Or who Mr or Mrs 'xlopez'  on http://common-lisp.net/websvn/listing.php?repname=ht-ajax 
   is?

Or who to ask for changing the .tar.gz file on common-lisp.net?


Thanks for your time,

Martin Loetzsch



From ron at flownet.com  Sat Jan 23 02:47:37 2010
From: ron at flownet.com (Ron Garret)
Date: Fri, 22 Jan 2010 18:47:37 -0800
Subject: [hunchentoot-devel] Returning a unicode string from a handler fails
	silently
Message-ID: <4A6E5A72-8F16-48A0-9429-2AA5E64330E7@flownet.com>

Subject line says it all.  If I have a handler that returns a string that has a non-ascii character in it then the handler fails silently.  No headers.  No log messages.  No errors.  No nothing.

And as long as I'm at it, what does TBNL stand for?

Thanks,
rg




From hans.huebner at gmail.com  Sat Jan 23 03:23:01 2010
From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Fri, 22 Jan 2010 19:23:01 -0800
Subject: [hunchentoot-devel] Returning a unicode string from a handler
	fails silently
In-Reply-To: <4A6E5A72-8F16-48A0-9429-2AA5E64330E7@flownet.com>
References: <4A6E5A72-8F16-48A0-9429-2AA5E64330E7@flownet.com>
Message-ID: <fd2982321001221923y7461664fx3e80a27344035ac2@mail.gmail.com>

On Fri, Jan 22, 2010 at 18:47, Ron Garret <ron at flownet.com> wrote:
> Subject line says it all. ?If I have a handler that returns a string that has a non-ascii character in it then the handler fails silently. ?No headers. ?No log messages. ?No errors. ?No nothing.

Does hunchtentoot-test fail for you as well?  What version of
Hunchentoot, compiler?  Where did you get the dependencies from?

> And as long as I'm at it, what does TBNL stand for?

T Be Named Later.

Cheers,
Hans



From ligong.ch at gmail.com  Sat Jan 23 03:32:24 2010
From: ligong.ch at gmail.com (Li Gong)
Date: Sat, 23 Jan 2010 11:32:24 +0800
Subject: [hunchentoot-devel] Returning a unicode string from a handler
	fails silently
In-Reply-To: <4A6E5A72-8F16-48A0-9429-2AA5E64330E7@flownet.com>
References: <4A6E5A72-8F16-48A0-9429-2AA5E64330E7@flownet.com>
Message-ID: <2e2fb4661001221932o3b531d7bi826c1c2d06fdba4c@mail.gmail.com>

What's the value of *hunchentoot-default-external-format* ?  By default,  it
is +latin-1+
To support UTF-8,    change it as
(setf *hunchentoot-default-external-format* (flex:make-external-format :utf8
:eol-style :lf))

My website still uses hunchentoot 0.15.7?It returns the non-ascii character
page and  always work fine.


2010/1/23 Ron Garret <ron at flownet.com>

> Subject line says it all.  If I have a handler that returns a string that
> has a non-ascii character in it then the handler fails silently.  No
> headers.  No log messages.  No errors.  No nothing.
>
> And as long as I'm at it, what does TBNL stand for?
>
> Thanks,
> rg
>
>
> _______________________________________________
> 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/20100123/c4f3ad1e/attachment.html>

From xach at xach.com  Sat Jan 23 03:18:40 2010
From: xach at xach.com (Zach Beane)
Date: Fri, 22 Jan 2010 22:18:40 -0500
Subject: [hunchentoot-devel] Returning a unicode string from a handler
	fails silently
In-Reply-To: <4A6E5A72-8F16-48A0-9429-2AA5E64330E7@flownet.com> (Ron Garret's
	message of "Fri, 22 Jan 2010 18:47:37 -0800")
References: <4A6E5A72-8F16-48A0-9429-2AA5E64330E7@flownet.com>
Message-ID: <87vdetcxv3.fsf@hangup.portland.xach.com>

Ron Garret <ron at flownet.com> writes:

> Subject line says it all.  If I have a handler that returns a string
> that has a non-ascii character in it then the handler fails silently.
> No headers.  No log messages.  No errors.  No nothing.

Works fine for me.

> And as long as I'm at it, what does TBNL stand for?

To Be Named Later.

Zach



From ron at flownet.com  Sat Jan 23 05:23:56 2010
From: ron at flownet.com (Ron Garret)
Date: Fri, 22 Jan 2010 21:23:56 -0800
Subject: [hunchentoot-devel] Returning a unicode string from a handler
	fails silently
In-Reply-To: <fd2982321001221923y7461664fx3e80a27344035ac2@mail.gmail.com>
References: <4A6E5A72-8F16-48A0-9429-2AA5E64330E7@flownet.com>
	<fd2982321001221923y7461664fx3e80a27344035ac2@mail.gmail.com>
Message-ID: <F8797A43-0ACE-4536-A5AC-181E79162ACB@flownet.com>


On Jan 22, 2010, at 7:23 PM, Hans H?bner wrote:

> On Fri, Jan 22, 2010 at 18:47, Ron Garret <ron at flownet.com> wrote:
>> Subject line says it all.  If I have a handler that returns a string that has a non-ascii character in it then the handler fails silently.  No headers.  No log messages.  No errors.  No nothing.
> 
> Does hunchtentoot-test fail for you as well?

No, that works.  Including the unicode tests.  But that's because those get run through ENC.  It's only if there's a non-HTML-entity-encoded unicode character in the returned string that it fails.

>  What version of Hunchentoot,

1.0.0

> compiler?

CCL trunk.

>  Where did you get the dependencies from?
> 

It's an Ediware snapshot from a few months ago.

rg




From ron at flownet.com  Sat Jan 23 05:27:12 2010
From: ron at flownet.com (Ron Garret)
Date: Fri, 22 Jan 2010 21:27:12 -0800
Subject: [hunchentoot-devel] Returning a unicode string from a handler
	fails silently
In-Reply-To: <2e2fb4661001221932o3b531d7bi826c1c2d06fdba4c@mail.gmail.com>
References: <4A6E5A72-8F16-48A0-9429-2AA5E64330E7@flownet.com>
	<2e2fb4661001221932o3b531d7bi826c1c2d06fdba4c@mail.gmail.com>
Message-ID: <EB82499B-3075-4922-97F4-BD41EE262011@flownet.com>

That was the problem.  But why did it fail silently?  I would have expected something along the line to complain about a non-encodable character.

rg

On Jan 22, 2010, at 7:32 PM, Li Gong wrote:

> What's the value of *hunchentoot-default-external-format* ?  By default,  it is +latin-1+
> To support UTF-8,    change it as
> (setf *hunchentoot-default-external-format* (flex:make-external-format :utf8 :eol-style :lf))
> 
> My website still uses hunchentoot 0.15.7?It returns the non-ascii character page and  always work fine.
> 
> 
> 2010/1/23 Ron Garret <ron at flownet.com>
> Subject line says it all.  If I have a handler that returns a string that has a non-ascii character in it then the handler fails silently.  No headers.  No log messages.  No errors.  No nothing.
> 
> And as long as I'm at it, what does TBNL stand for?
> 
> Thanks,
> rg
> 
> 
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
> 
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20100122/6403f39b/attachment.html>

From ligong.ch at gmail.com  Sat Jan 23 10:25:49 2010
From: ligong.ch at gmail.com (Li Gong)
Date: Sat, 23 Jan 2010 18:25:49 +0800
Subject: [hunchentoot-devel] Returning a unicode string from a handler
	fails silently
In-Reply-To: <EB82499B-3075-4922-97F4-BD41EE262011@flownet.com>
References: <4A6E5A72-8F16-48A0-9429-2AA5E64330E7@flownet.com>
	<2e2fb4661001221932o3b531d7bi826c1c2d06fdba4c@mail.gmail.com>
	<EB82499B-3075-4922-97F4-BD41EE262011@flownet.com>
Message-ID: <2e2fb4661001230225x34f8249el69c1111ff65af150@mail.gmail.com>

By default, the debugger is not entered, but the error info appears in
/tmp/hunchentoot.log, e.g.
[ERROR]] Error while processing connection: #\U4F60 (code 20320) is not a
LATIN-1 character.

In 1.0 release,  *break-on-signals* is used to enter the debugger
In the old release and 1.1,  when *catch-errors-p* is set as nil, the
debugger will be entered.
The related discussion thread can be found at:
http://common-lisp.net/pipermail/tbnl-devel/2009-November/004928.html

cheers
Li


2010/1/23 Ron Garret <ron at flownet.com>

> That was the problem.  But why did it fail silently?  I would have expected
> something along the line to complain about a non-encodable character.
>
> rg
>
> On Jan 22, 2010, at 7:32 PM, Li Gong wrote:
>
> What's the value of *hunchentoot-default-external-format* ?  By default,
> it is +latin-1+
> To support UTF-8,    change it as
> (setf *hunchentoot-default-external-format* (flex:make-external-format
> :utf8 :eol-style :lf))
>
> My website still uses hunchentoot 0.15.7?It returns the non-ascii character
> page and  always work fine.
>
>
> 2010/1/23 Ron Garret <ron at flownet.com>
>
>> Subject line says it all.  If I have a handler that returns a string that
>> has a non-ascii character in it then the handler fails silently.  No
>> headers.  No log messages.  No errors.  No nothing.
>>
>> And as long as I'm at it, what does TBNL stand for?
>>
>> Thanks,
>> rg
>>
>>
>> _______________________________________________
>> tbnl-devel site list
>> tbnl-devel at common-lisp.net
>> http://common-lisp.net/mailman/listinfo/tbnl-devel
>>
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>
>
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20100123/e231b3a4/attachment.html>

From ron at flownet.com  Sat Jan 23 16:21:02 2010
From: ron at flownet.com (Ron Garret)
Date: Sat, 23 Jan 2010 08:21:02 -0800
Subject: [hunchentoot-devel] Returning a unicode string from a handler
	fails silently
In-Reply-To: <2e2fb4661001230225x34f8249el69c1111ff65af150@mail.gmail.com>
References: <4A6E5A72-8F16-48A0-9429-2AA5E64330E7@flownet.com>
	<2e2fb4661001221932o3b531d7bi826c1c2d06fdba4c@mail.gmail.com>
	<EB82499B-3075-4922-97F4-BD41EE262011@flownet.com>
	<2e2fb4661001230225x34f8249el69c1111ff65af150@mail.gmail.com>
Message-ID: <7C9B3B17-5E77-4A92-ADFC-6878830DFC4D@flownet.com>


On Jan 23, 2010, at 2:25 AM, Li Gong wrote:

> By default, the debugger is not entered, but the error info appears in /tmp/hunchentoot.log,

Nope:

[ron at mickey:/tmp]$ pwd
/tmp
[ron at mickey:/tmp]$ ls hun*
ls: hun*: No such file or directory

I have generated other errors and log messages that showed up in the AltConsole (this is a CCL thing in case you don't know) but in this case nothing showed up there either.

rg




From edi at agharta.de  Sat Jan 23 16:38:03 2010
From: edi at agharta.de (Edi Weitz)
Date: Sat, 23 Jan 2010 17:38:03 +0100
Subject: [hunchentoot-devel] Returning a unicode string from a handler
	fails silently
In-Reply-To: <7C9B3B17-5E77-4A92-ADFC-6878830DFC4D@flownet.com>
References: <4A6E5A72-8F16-48A0-9429-2AA5E64330E7@flownet.com>
	<2e2fb4661001221932o3b531d7bi826c1c2d06fdba4c@mail.gmail.com>
	<EB82499B-3075-4922-97F4-BD41EE262011@flownet.com>
	<2e2fb4661001230225x34f8249el69c1111ff65af150@mail.gmail.com>
	<7C9B3B17-5E77-4A92-ADFC-6878830DFC4D@flownet.com>
Message-ID: <b56421a01001230838w70598482sfcb88aacfa7a6a06@mail.gmail.com>

On Sat, Jan 23, 2010 at 5:21 PM, Ron Garret <ron at flownet.com> wrote:
>
> On Jan 23, 2010, at 2:25 AM, Li Gong wrote:
>
>> By default, the debugger is not entered, but the error info appears in /tmp/hunchentoot.log,
>
> Nope:

Most things in Hunchentoot are documented and so is logging:

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

Logging to /tmp/hunchentoot.log was the default behaviour for pre-1.0
versions (on Unix-y systems), but it isn't anymore.

Edi.



From ron at flownet.com  Sat Jan 23 16:49:05 2010
From: ron at flownet.com (Ron Garret)
Date: Sat, 23 Jan 2010 08:49:05 -0800
Subject: [hunchentoot-devel] Returning a unicode string from a handler
	fails silently
In-Reply-To: <b56421a01001230838w70598482sfcb88aacfa7a6a06@mail.gmail.com>
References: <4A6E5A72-8F16-48A0-9429-2AA5E64330E7@flownet.com>
	<2e2fb4661001221932o3b531d7bi826c1c2d06fdba4c@mail.gmail.com>
	<EB82499B-3075-4922-97F4-BD41EE262011@flownet.com>
	<2e2fb4661001230225x34f8249el69c1111ff65af150@mail.gmail.com>
	<7C9B3B17-5E77-4A92-ADFC-6878830DFC4D@flownet.com>
	<b56421a01001230838w70598482sfcb88aacfa7a6a06@mail.gmail.com>
Message-ID: <EE18D0BD-D5ED-4072-88F9-B6771B425AF1@flownet.com>


On Jan 23, 2010, at 8:38 AM, Edi Weitz wrote:

> On Sat, Jan 23, 2010 at 5:21 PM, Ron Garret <ron at flownet.com> wrote:
>> 
>> On Jan 23, 2010, at 2:25 AM, Li Gong wrote:
>> 
>>> By default, the debugger is not entered, but the error info appears in /tmp/hunchentoot.log,
>> 
>> Nope:
> 
> Most things in Hunchentoot are documented and so is logging:
> 
>  http://weitz.de/hunchentoot/#logging
> 
> Logging to /tmp/hunchentoot.log was the default behaviour for pre-1.0
> versions (on Unix-y systems), but it isn't anymore.
> 

Yes, I RTFM.  I have *show-lisp-errors-p* set to T.  Errors in other parts of the code show up just as I would expect.  Log messages show up in the AltConsole.  I've been happily debugging all manner of issues all day long.  But this particular problem produces no debugging output that I can find.

rg




From ron at flownet.com  Sat Jan 23 17:05:47 2010
From: ron at flownet.com (Ron Garret)
Date: Sat, 23 Jan 2010 09:05:47 -0800
Subject: [hunchentoot-devel] Returning a unicode string from a handler
	fails silently
In-Reply-To: <EE18D0BD-D5ED-4072-88F9-B6771B425AF1@flownet.com>
References: <4A6E5A72-8F16-48A0-9429-2AA5E64330E7@flownet.com>
	<2e2fb4661001221932o3b531d7bi826c1c2d06fdba4c@mail.gmail.com>
	<EB82499B-3075-4922-97F4-BD41EE262011@flownet.com>
	<2e2fb4661001230225x34f8249el69c1111ff65af150@mail.gmail.com>
	<7C9B3B17-5E77-4A92-ADFC-6878830DFC4D@flownet.com>
	<b56421a01001230838w70598482sfcb88aacfa7a6a06@mail.gmail.com>
	<EE18D0BD-D5ED-4072-88F9-B6771B425AF1@flownet.com>
Message-ID: <6E03B050-3D0B-4EBB-AB88-B112FB8FBCCF@flownet.com>


On Jan 23, 2010, at 8:49 AM, Ron Garret wrote:

> 
> On Jan 23, 2010, at 8:38 AM, Edi Weitz wrote:
> 
>> On Sat, Jan 23, 2010 at 5:21 PM, Ron Garret <ron at flownet.com> wrote:
>>> 
>>> On Jan 23, 2010, at 2:25 AM, Li Gong wrote:
>>> 
>>>> By default, the debugger is not entered, but the error info appears in /tmp/hunchentoot.log,
>>> 
>>> Nope:
>> 
>> Most things in Hunchentoot are documented and so is logging:
>> 
>> http://weitz.de/hunchentoot/#logging
>> 
>> Logging to /tmp/hunchentoot.log was the default behaviour for pre-1.0
>> versions (on Unix-y systems), but it isn't anymore.
>> 
> 
> Yes, I RTFM.  I have *show-lisp-errors-p* set to T.  Errors in other parts of the code show up just as I would expect.  Log messages show up in the AltConsole.  I've been happily debugging all manner of issues all day long.  But this particular problem produces no debugging output that I can find.

OK, I figured it out.  What I was seeing on the AltConsole was not logging output, it was the output of print statements in my code.  I set *MESSAGE-LOG-PATHNAME* and all is now well.

rg




From avodonosov at yandex.ru  Mon Jan 25 20:25:04 2010
From: avodonosov at yandex.ru (Anton Vodonosov)
Date: Mon, 25 Jan 2010 22:25:04 +0200
Subject: [hunchentoot-devel] Exception in USOCKET:GET-PEER-ADDRESS brakes
	ACCEPT-CONNECTIONS loop
Message-ID: <8310531763.20100125222504@yandex.ru>

Hello,

On one server running hunchentoot quite often the following error occurs:

 23: (SB-IMPL::%WITH-STANDARD-IO-SYNTAX #)
 24: (INVOKE-DEBUGGER #)
 25: (ERROR SB-BSD-SOCKETS:NOT-CONNECTED-ERROR)[:EXTERNAL]
 26: (SB-BSD-SOCKETS:SOCKET-ERROR "getpeername")
 27: ((SB-PCL::FAST-METHOD SB-BSD-SOCKETS:SOCKET-PEERNAME (SB-BSD-SOCKETS:SOCKET)) # # #)
 28: ((SB-PCL::FAST-METHOD USOCKET:GET-PEER-ADDRESS (USOCKET:STREAM-USOCKET)) # # #)
 29: (HUNCHENTOOT::CLIENT-AS-STRING #)
 30: ((SB-PCL::FAST-METHOD HUNCHENTOOT:HANDLE-INCOMING-CONNECTION (HUNCHENTOOT:ONE-THREAD-PER-CONNECTION-TASKMASTER T)) ..)
 31: ((SB-PCL::FAST-METHOD HUNCHENTOOT:ACCEPT-CONNECTIONS (HUNCHENTOOT:ACCEPTOR)) # # #)
 32: ((LAMBDA ()))


As you see, it happens in USOCKET:GET-PEER-ADDRESS called in
HANDLE-INCOMING-CONNECTION before the request handling thread is
started.

This exception breaks the main loop in ACCEPT-CONNECTIONS and server
doesn't handle HTTP requests anymore.

Most probably these errors are very rare in general, but on this
particular machine they happen constantly.

Adding ignore-errors to the loop helps - the server doesn't hang
anymore.

Best regard,
- Anton


P.S. The problem and the fix suggested are discovered by
Andrey Moskvitin, I am just reporting it here.





From hans.huebner at gmail.com  Tue Jan 26 10:16:55 2010
From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Tue, 26 Jan 2010 11:16:55 +0100
Subject: [hunchentoot-devel] Exception in USOCKET:GET-PEER-ADDRESS
	brakes ACCEPT-CONNECTIONS loop
In-Reply-To: <8310531763.20100125222504@yandex.ru>
References: <8310531763.20100125222504@yandex.ru>
Message-ID: <fd2982321001260216v1805cde6i4019819bc54c5820@mail.gmail.com>

On Mon, Jan 25, 2010 at 21:25, Anton Vodonosov <avodonosov at yandex.ru> wrote:
> On one server running hunchentoot quite often the following error occurs:
>
> ?23: (SB-IMPL::%WITH-STANDARD-IO-SYNTAX #)
> ?24: (INVOKE-DEBUGGER #)
> ?25: (ERROR SB-BSD-SOCKETS:NOT-CONNECTED-ERROR)[:EXTERNAL]
> ?26: (SB-BSD-SOCKETS:SOCKET-ERROR "getpeername")
> ?27: ((SB-PCL::FAST-METHOD SB-BSD-SOCKETS:SOCKET-PEERNAME (SB-BSD-SOCKETS:SOCKET)) # # #)

I think you need to set *CATCH-ERRORS-P* to a non-NIL value in order
to prevent the debugger from being entered when an error is signaled.
To me, this looks right:

#-:lispworks
(defmethod handle-incoming-connection ((taskmaster
one-thread-per-connection-taskmaster) socket)
  ;; we are handling all conditions here as we want to make sure that
  ;; the acceptor process never crashes while trying to create a
  ;; worker thread; one such problem exists in
  ;; GET-PEER-ADDRESS-AND-PORT which can signal socket conditions on
  ;; some platforms in certain situations.
  (handler-case*
      (bt:make-thread (lambda ()
                        (process-connection (taskmaster-acceptor
taskmaster) socket))
                      :name (format nil "Hunchentoot worker \(client:
~A)" (client-as-string socket)))

    (error (cond)
      ;; need to bind *ACCEPTOR* so that LOG-MESSAGE can do its work.
      (let ((*acceptor* (taskmaster-acceptor taskmaster)))
        (log-message *lisp-errors-log-level*
                     "Error while creating worker thread for new
incoming connection: ~A" cond)))))

I might certainly be missing something, so please let me know if this
is the case.  For production installations, it is not advisable to
have *CATCH-ERRORS-P* to be set to NIL.

-Hans



From archimag at gmail.com  Tue Jan 26 10:29:30 2010
From: archimag at gmail.com (Andrey Moskvitin)
Date: Tue, 26 Jan 2010 13:29:30 +0300
Subject: [hunchentoot-devel] Exception in USOCKET:GET-PEER-ADDRESS
	brakes ACCEPT-CONNECTIONS loop
In-Reply-To: <fd2982321001260216v1805cde6i4019819bc54c5820@mail.gmail.com>
References: <8310531763.20100125222504@yandex.ru>
	<fd2982321001260216v1805cde6i4019819bc54c5820@mail.gmail.com>
Message-ID: <e0c33b911001260229p4481619h25ae3aa233269415@mail.gmail.com>

> I think you need to set *CATCH-ERRORS-P* to a non-NIL value in order
> to prevent the debugger from being entered when an error is signaled.

Of course, this is a working server and * catch-errors-p * is set to T.
The problem arises not because of this.

Andrey


26 ?????? 2010 ?. 13:16 ???????????? Hans H?bner
<hans.huebner at gmail.com>???????:

> On Mon, Jan 25, 2010 at 21:25, Anton Vodonosov <avodonosov at yandex.ru>
> wrote:
> > On one server running hunchentoot quite often the following error occurs:
> >
> >  23: (SB-IMPL::%WITH-STANDARD-IO-SYNTAX #)
> >  24: (INVOKE-DEBUGGER #)
> >  25: (ERROR SB-BSD-SOCKETS:NOT-CONNECTED-ERROR)[:EXTERNAL]
> >  26: (SB-BSD-SOCKETS:SOCKET-ERROR "getpeername")
> >  27: ((SB-PCL::FAST-METHOD SB-BSD-SOCKETS:SOCKET-PEERNAME
> (SB-BSD-SOCKETS:SOCKET)) # # #)
>
> I think you need to set *CATCH-ERRORS-P* to a non-NIL value in order
> to prevent the debugger from being entered when an error is signaled.
> To me, this looks right:
>
> #-:lispworks
> (defmethod handle-incoming-connection ((taskmaster
> one-thread-per-connection-taskmaster) socket)
>  ;; we are handling all conditions here as we want to make sure that
>  ;; the acceptor process never crashes while trying to create a
>  ;; worker thread; one such problem exists in
>  ;; GET-PEER-ADDRESS-AND-PORT which can signal socket conditions on
>  ;; some platforms in certain situations.
>  (handler-case*
>      (bt:make-thread (lambda ()
>                        (process-connection (taskmaster-acceptor
> taskmaster) socket))
>                      :name (format nil "Hunchentoot worker \(client:
> ~A)" (client-as-string socket)))
>
>    (error (cond)
>      ;; need to bind *ACCEPTOR* so that LOG-MESSAGE can do its work.
>      (let ((*acceptor* (taskmaster-acceptor taskmaster)))
>        (log-message *lisp-errors-log-level*
>                     "Error while creating worker thread for new
> incoming connection: ~A" cond)))))
>
> I might certainly be missing something, so please let me know if this
> is the case.  For production installations, it is not advisable to
> have *CATCH-ERRORS-P* to be set to NIL.
>
> -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/20100126/80441c92/attachment.html>

From hans.huebner at gmail.com  Tue Jan 26 11:07:26 2010
From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Tue, 26 Jan 2010 12:07:26 +0100
Subject: [hunchentoot-devel] Exception in USOCKET:GET-PEER-ADDRESS
	brakes ACCEPT-CONNECTIONS loop
In-Reply-To: <e0c33b911001260229p4481619h25ae3aa233269415@mail.gmail.com>
References: <8310531763.20100125222504@yandex.ru>
	<fd2982321001260216v1805cde6i4019819bc54c5820@mail.gmail.com> 
	<e0c33b911001260229p4481619h25ae3aa233269415@mail.gmail.com>
Message-ID: <fd2982321001260307m1532c393i54f2f9fc0f8e35f@mail.gmail.com>

On Tue, Jan 26, 2010 at 11:29, Andrey Moskvitin <archimag at gmail.com> wrote:
>> I think you need to set *CATCH-ERRORS-P* to a non-NIL value in order
>> to prevent the debugger from being entered when an error is signaled.
> Of course, this is a working server and * catch-errors-p * is set to T.
> The problem arises not because of this.

[...]

>> > ?23: (SB-IMPL::%WITH-STANDARD-IO-SYNTAX #)
>> > ?24: (INVOKE-DEBUGGER #)
>> > ?25: (ERROR SB-BSD-SOCKETS:NOT-CONNECTED-ERROR)[:EXTERNAL]

Can you then please explain why INVOKE-DEBUGGER is called?  From my
reading of the source code, it would only be called if
*CATCH-ERRORS-P* is NIL, but I may be missing something.

-Hans



From archimag at gmail.com  Tue Jan 26 12:28:37 2010
From: archimag at gmail.com (Andrey Moskvitin)
Date: Tue, 26 Jan 2010 15:28:37 +0300
Subject: [hunchentoot-devel] Exception in USOCKET:GET-PEER-ADDRESS
	brakes ACCEPT-CONNECTIONS loop
In-Reply-To: <fd2982321001260307m1532c393i54f2f9fc0f8e35f@mail.gmail.com>
References: <8310531763.20100125222504@yandex.ru>
	<fd2982321001260216v1805cde6i4019819bc54c5820@mail.gmail.com>
	<e0c33b911001260229p4481619h25ae3aa233269415@mail.gmail.com>
	<fd2982321001260307m1532c393i54f2f9fc0f8e35f@mail.gmail.com>
Message-ID: <e0c33b911001260428q3605169dn9f2892f791eff26@mail.gmail.com>

I realized I had this problem with hunchentoot-1.0. I corrected it for
myself, tested within a month and wrote up in my blog on January 9. This
happened before the release of version 1.1.   In hunchentoot-1.0 is the
following code:

#-:lispworks
(defmethod handle-incoming-connection ((taskmaster
one-thread-per-connection-taskmaster) socket)
  (bt:make-thread (lambda ()
                    (process-connection (taskmaster-acceptor taskmaster)
socket))
                  :name (format nil "Hunchentoot worker \(client: ~A)"
(client-as-string socket))))

Which is now fixed, but it seems there was no special message about it:)

Andrey

2010/1/26 Hans H?bner <hans.huebner at gmail.com>

> On Tue, Jan 26, 2010 at 11:29, Andrey Moskvitin <archimag at gmail.com>
> wrote:
> >> I think you need to set *CATCH-ERRORS-P* to a non-NIL value in order
> >> to prevent the debugger from being entered when an error is signaled.
> > Of course, this is a working server and * catch-errors-p * is set to T.
> > The problem arises not because of this.
>
> [...]
>
> >> >  23: (SB-IMPL::%WITH-STANDARD-IO-SYNTAX #)
> >> >  24: (INVOKE-DEBUGGER #)
> >> >  25: (ERROR SB-BSD-SOCKETS:NOT-CONNECTED-ERROR)[:EXTERNAL]
>
> Can you then please explain why INVOKE-DEBUGGER is called?  From my
> reading of the source code, it would only be called if
> *CATCH-ERRORS-P* is NIL, but I may be missing something.
>
> -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/20100126/5662b1c0/attachment.html>

From patrick.may at mac.com  Thu Jan 28 14:57:03 2010
From: patrick.may at mac.com (Patrick May)
Date: Thu, 28 Jan 2010 09:57:03 -0500
Subject: [hunchentoot-devel] Authorization data being cached
Message-ID: <66963134-0CEF-4FE7-A774-809836142523@mac.com>

	I don't think this is a Hunchentoot issue, but I thought I'd ask here first.  I've noticed that Safari seems to cache the basic authorization username and password, so that even if I call (remove-session *session*) on the server side, Safari just reloads the page.

	Am I interpreting the behavior correctly?  If so, how do I force a re-authorization?

Thanks,

Patrick

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2421 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20100128/0558be73/attachment.bin>

From asf at boinkor.net  Thu Jan 28 16:09:11 2010
From: asf at boinkor.net (Andreas Fuchs)
Date: Thu, 28 Jan 2010 17:09:11 +0100
Subject: [hunchentoot-devel] Authorization data being cached
In-Reply-To: <66963134-0CEF-4FE7-A774-809836142523@mac.com>
References: <66963134-0CEF-4FE7-A774-809836142523@mac.com>
Message-ID: <b59bc8ff1001280809p185adaa8s9a1e3615e5cb9c8c@mail.gmail.com>

On Thu, Jan 28, 2010 at 15:57, Patrick May <patrick.may at mac.com> wrote:
> ? ? ? ?I don't think this is a Hunchentoot issue, but I thought I'd ask here first. ?I've noticed that Safari seems to cache the basic authorization username and password, so that even if I call (remove-session *session*) on the server side, Safari just reloads the page.

AFAIK, every browser does this. It's the only way HTTP Basic auth can
work without being terribly annoying to the user.

> ? ? ? ?Am I interpreting the behavior correctly? ?If so, how do I force a re-authorization?

To "log out" the user, you need to return a 401 Unauthorized status
(see http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html), which
will prompt the browser to display the user/password dialog box again.
If the user presses Cancel enough times, they'll finally be logged
out.

It's terribly convoluted, but that's Basic auth for you /-:

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



From ron at flownet.com  Thu Jan 28 16:51:21 2010
From: ron at flownet.com (Ron Garret)
Date: Thu, 28 Jan 2010 08:51:21 -0800
Subject: [hunchentoot-devel] Authorization data being cached
In-Reply-To: <b59bc8ff1001280809p185adaa8s9a1e3615e5cb9c8c@mail.gmail.com>
References: <66963134-0CEF-4FE7-A774-809836142523@mac.com>
	<b59bc8ff1001280809p185adaa8s9a1e3615e5cb9c8c@mail.gmail.com>
Message-ID: <3007BF45-3594-4B02-AEE1-2123297D75B1@flownet.com>


On Jan 28, 2010, at 8:09 AM, Andreas Fuchs wrote:

> On Thu, Jan 28, 2010 at 15:57, Patrick May <patrick.may at mac.com> wrote:
>>        I don't think this is a Hunchentoot issue, but I thought I'd ask here first.  I've noticed that Safari seems to cache the basic authorization username and password, so that even if I call (remove-session *session*) on the server side, Safari just reloads the page.
> 
> AFAIK, every browser does this. It's the only way HTTP Basic auth can
> work without being terribly annoying to the user.
> 
>>        Am I interpreting the behavior correctly?  If so, how do I force a re-authorization?
> 
> To "log out" the user, you need to return a 401 Unauthorized status
> (see http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html), which
> will prompt the browser to display the user/password dialog box again.
> If the user presses Cancel enough times, they'll finally be logged
> out.
> 
> It's terribly convoluted, but that's Basic auth for you /-:

Yes.  That is why IMHO basic auth (and in fact all HTTP auth schemes) should never be used.  They are fundamentally b0rken.

rg




From arjan at streamtech.nl  Thu Jan 28 16:54:59 2010
From: arjan at streamtech.nl (Arjan Wekking)
Date: Thu, 28 Jan 2010 17:54:59 +0100
Subject: [hunchentoot-devel] Authorization data being cached
In-Reply-To: <66963134-0CEF-4FE7-A774-809836142523@mac.com>
References: <66963134-0CEF-4FE7-A774-809836142523@mac.com>
Message-ID: <057E2D21-4777-4AC0-A919-407BB33A4504@streamtech.nl>

On 28 jan 2010, at 15:57, Patrick May wrote:

> 	I don't think this is a Hunchentoot issue, but I thought I'd ask  
> here first.  I've noticed that Safari seems to cache the basic  
> authorization username and password, so that even if I call (remove- 
> session *session*) on the server side, Safari just reloads the page.

As far as I know, Hunchentoot sessions have nothing to do with HTTP  
basic authentication, of which Safari can indeed store the credentials  
in the OS X Keychain (other browsers like Firefox or Chrome also allow  
you to 'save your username and password' somewhere).

All browsers actually 'cache' HTTP authentication credentials one way  
or another between HTTP requests and usually forget them when you  
close the window and/or tab that was authenticated [1]. This is not  
the same as storing them in the Keychain but just part of how a HTTP  
authentication 'session' works in browsers.

Standard Hunchentoot sessions have nothing to do with HTTP  
authentication unless you've re-implemented them to use HTTP  
authentication credentials as session identifiers somehow (which would  
be an interesting approach but that's not really relevant right now).

> 	Am I interpreting the behavior correctly?  If so, how do I force a  
> re-authorization?

With HTTP authentication, the simple anser is that you can't. Logging  
in and out is under the HTTP client's control (where it in my opinion  
should be). Unfortunately there's no good UI in browsers yet to  
gracefully log in and out with HTTP authentication. Heck, you can't  
even see *if* your browser is supplying any HTTP credentials without  
inspecting your own HTTP requests.

Theoretically, you can do something like:

    (setf (return-code*) +http-authentication-required+)

Which basically means that your webserver is telling the HTTP client  
that whatever it supplied as credentials in the current request is not  
accepted anymore (401 Unauthorized) and that it, in other words,  
should supply other credentials. Some browsers will then clear the  
'cached' credentials and ask the user to supply new ones.

This means that in browsers that do not store credentials, you will be  
presented with a new 'please enter your username and password' dialog  
again, right after logging out, and there's no way around this. I  
think Safari, in this case, simply fetches them from the Keychain  
again and silently 'logs in' again without the user even noticing, but  
I'm not entirely sure about this.

Either way, it's not a real solution.

One thing that might work is to embed the Hunchentoot session ID into  
the basic authentication 'realm', in which case (remove-session  
*session*) actually works. But, by doing this, you effectively break  
the whole 'store this username and password in my keychain' feature of  
Safari and similar 'remember this username and password' features of  
all browsers, because the browsers will store them along with the  
realm and when the realm changes, it cannot reuse these stored  
credentials.

The other way is to use cookie or URL based session and store the  
authentication status in the server. This is where the Hunchentoot  
session would come in and in this case you would probably need to  
build a simple log-in HTML form, although it's possible to use HTTP  
authentication to 'authenticate' the session as well and offer both a  
public login form and HTTP authentication when directly accessing  
protected resources and still have a 'log out' option that simply  
destroys or de-authenticates the session server-side.

I hope this all makes some sense :]

-Arjan

[1] http://en.wikipedia.org/wiki/Basic_access_authentication
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4411 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20100128/5daa6883/attachment.bin>