From edi at agharta.de  Tue Jun  3 11:30:50 2008
From: edi at agharta.de (Edi Weitz)
Date: Tue, 03 Jun 2008 07:30:50 -0400
Subject: [hunchentoot-devel] Re: trivial-backtrace
In-Reply-To: <657D4000-26F0-4B95-9DF0-A36C6228FA2D@metabang.com> (Gary
	King's message of "Tue, 3 Jun 2008 04:44:52 -0400")
References: <657D4000-26F0-4B95-9DF0-A36C6228FA2D@metabang.com>
Message-ID: <u7id6ycut.fsf@agharta.de>

On Tue, 3 Jun 2008 04:44:52 -0400, Gary King <gwking at metabang.com> wrote:

> I finally made some time to finish this and get it on cl-net. It'll
> al be up on cl.net as soon as my flakey internet connection allows.

[Ccing tbnl-devel as this'll affect current Hunchentoot.]

Thanks, looks fine to me.  Two comments:

1. grep will find "hunchentoot" several times in backtrace.lisp which
   is probably not necessary.  Simply mentioning where this part of
   the code originates from would suffice... :)

2. I think a fallback function which does nothing or signals an error
   (maybe depending on the choice of the library user) for
   implementations which aren't supported would be fine.

Otherwise I'm fine with using this for the next Hunchentoot release
unless someone opposes.

Thanks,
Edi.


From gwking at metabang.com  Tue Jun  3 13:41:25 2008
From: gwking at metabang.com (Gary King)
Date: Tue, 3 Jun 2008 15:41:25 +0200
Subject: [hunchentoot-devel] Re: trivial-backtrace
In-Reply-To: <u7id6ycut.fsf@agharta.de>
References: <657D4000-26F0-4B95-9DF0-A36C6228FA2D@metabang.com>
	<u7id6ycut.fsf@agharta.de>
Message-ID: <6AB0A160-B143-4647-B127-3D292A4F5A9F@metabang.com>

Hi Edi,

Good ideas. I'll implement them both (maybe on the plane back to the  
states)

Sent from my iPhone

On Jun 3, 2008, at 1:30 PM, Edi Weitz <edi at agharta.de> wrote:

> On Tue, 3 Jun 2008 04:44:52 -0400, Gary King <gwking at metabang.com>  
> wrote:
>
>> I finally made some time to finish this and get it on cl-net. It'll
>> al be up on cl.net as soon as my flakey internet connection allows.
>
> [Ccing tbnl-devel as this'll affect current Hunchentoot.]
>
> Thanks, looks fine to me.  Two comments:
>
> 1. grep will find "hunchentoot" several times in backtrace.lisp which
>   is probably not necessary.  Simply mentioning where this part of
>   the code originates from would suffice... :)
>
> 2. I think a fallback function which does nothing or signals an error
>   (maybe depending on the choice of the library user) for
>   implementations which aren't supported would be fine.
>
> Otherwise I'm fine with using this for the next Hunchentoot release
> unless someone opposes.
>
> Thanks,
> Edi.


From larsnostdal at gmail.com  Tue Jun 10 09:23:44 2008
From: larsnostdal at gmail.com (=?UTF-8?B?TGFycyBSdW5lIE7DuHN0ZGFs?=)
Date: Tue, 10 Jun 2008 11:23:44 +0200
Subject: [hunchentoot-devel] Re: Current development
In-Reply-To: <u4p8lb050.fsf@agharta.de>
References: <u4p8lb050.fsf@agharta.de>
Message-ID: <g2lh70$82j$1@ger.gmane.org>

Edi Weitz wrote:
> As common-lisp.net has been pretty unreliable in the last days, we've
> moved development over to the bknr.net server maintained by Hans.  If
> you're interested in trying out the soon-to-be-released Hunchentoot
> version, get all of Hunchentoot, Chunga, and FLEXI-STREAMS from here:
> 
>   http://bknr.net/trac/browser/trunk/thirdparty
> 
> If you're using Drakma, you'll have to grab it from bknr.net as well,
> as there are incompatible changes in Chunga.
> 
> The previous development history can be seen at
> 
>   http://trac.common-lisp.net/tbnl/browser/branches
> 
> whenever the server is up.
> 
> Edi.

Hi,
I've been playing around with the new branch and the new CONNECTION-MANAGER etc. Being able to control threads or handling of incoming connections is nice.

But something I'm missing from HT is the ability to control the stream or connection after this. SEND-HEADERS did not seem to work as I needed because if I "collect" the stream returned from that function for usage later, and let the request-thread it originated from die it seems the old HT has been closing that stream which of course causes problems when I later wanted to use the "collected" streams.

In the new HT this doesn't seem to happen (I think?), but the stream is of a binary type. I was wondering -- how do I send text to this stream? .. and I'm also wondering whether what I'm seeing is a random glitch by ways of timing or something, and that HT in fact will close the stream for me in this version also?

I'm working on a "comet" server. Hence the somewhat unusual way of dealing with connections/streams.

Thanks,
-- 
Lars Rune N?stdal
http://nostdal.org/



From edi at agharta.de  Tue Jun 10 09:39:23 2008
From: edi at agharta.de (Edi Weitz)
Date: Tue, 10 Jun 2008 11:39:23 +0200
Subject: [hunchentoot-devel] Re: Current development
In-Reply-To: <g2lh70$82j$1@ger.gmane.org> (Lars Rune
	=?iso-8859-1?q?N=F8stdal's?= message of "Tue,
	10 Jun 2008 11:23:44 +0200")
References: <u4p8lb050.fsf@agharta.de> <g2lh70$82j$1@ger.gmane.org>
Message-ID: <uy75dljck.fsf@agharta.de>

On Tue, 10 Jun 2008 11:23:44 +0200, Lars Rune N?stdal <larsnostdal at gmail.com> wrote:

> But something I'm missing from HT is the ability to control the
> stream or connection after this. SEND-HEADERS did not seem to work
> as I needed because if I "collect" the stream returned from that
> function for usage later, and let the request-thread it originated
> from die it seems the old HT has been closing that stream which of
> course causes problems when I later wanted to use the "collected"
> streams.

The stream you get from SEND-HEADERS is only good for handling the
current request, it is up to Hunchentoot what it does with this stream
later on and it depends on what has been negotiated between the client
and the server.  There are situations where the server must close the
stream and there are situations where the server must re-use it and
read the next request from it.  The server must also be able to switch
chunking on and off between requests if needed.

So, if you're trying to "keep" the stream between requests, that won't
work.

With respect to this, the old and the new Hunchentoot should behave
the same.  If they're not, that's probably an error.

> In the new HT this doesn't seem to happen (I think?), but the stream
> is of a binary type. I was wondering -- how do I send text to this
> stream?

Yes, this is new.  The rationale is that if you want maximum
convenience and protection from errors, you just send content to
Hunchentoot and let it take care of sending the right data to the
client.  If you request a stream, you're likely doing this for
performance reasons or because you want to do something special, so it
seems right to give you the "raw" binary stream.  If you want to send
text to this stream, wrap it with a flexi stream, see for example
stream-direct-utf-8 here:

  http://bknr.net/trac/browser/trunk/thirdparty/hunchentoot/test/test.lisp

> .. and I'm also wondering whether what I'm seeing is a random glitch
> by ways of timing or something, and that HT in fact will close the
> stream for me in this version also?

See above.  If you think there's a situation where Huchentoot should
close a stream but it doesn't, that's an error.  A test case would be
nice.

> I'm working on a "comet" server. Hence the somewhat unusual way of
> dealing with connections/streams.

I don't know what theat is, unfortunately,

Cheers,
Edi.


From larsnostdal at gmail.com  Tue Jun 10 10:25:22 2008
From: larsnostdal at gmail.com (=?UTF-8?B?TGFycyBSdW5lIE7DuHN0ZGFs?=)
Date: Tue, 10 Jun 2008 12:25:22 +0200
Subject: [hunchentoot-devel] Re: Current development
In-Reply-To: <uy75dljck.fsf@agharta.de>
References: <u4p8lb050.fsf@agharta.de> <g2lh70$82j$1@ger.gmane.org>
	<uy75dljck.fsf@agharta.de>
Message-ID: <g2lkqk$kcl$1@ger.gmane.org>

Edi Weitz wrote:
> On Tue, 10 Jun 2008 11:23:44 +0200, Lars Rune N?stdal <larsnostdal at gmail.com> wrote:
> 
>> But something I'm missing from HT is the ability to control the
>> stream or connection after this. SEND-HEADERS did not seem to work
>> as I needed because if I "collect" the stream returned from that
>> function for usage later, and let the request-thread it originated
>> from die it seems the old HT has been closing that stream which of
>> course causes problems when I later wanted to use the "collected"
>> streams.
> 
> The stream you get from SEND-HEADERS is only good for handling the
> current request, it is up to Hunchentoot what it does with this stream
> later on and it depends on what has been negotiated between the client
> and the server.  There are situations where the server must close the
> stream and there are situations where the server must re-use it and
> read the next request from it.  The server must also be able to switch
> chunking on and off between requests if needed.
> 
> So, if you're trying to "keep" the stream between requests, that won't
> work.

I am keeping it so I can respond to the current request - but to do so later, from a different thread. This might seem strange, I know, but it is useful here. x)

Think of it as a sort of "hanging" or waiting response on the server end, and there are many of them -- a lot, so one thread pr. client with a wait condition or something isn't going to work. The threads (connection-manager again) are to be fetched from a pool and they got to end up back in it when there isn't any more "real" work to do.

I tried to save a closure with the stream (returned from send-headers) in it and I was intending to call it later when the server has something it wants to push to that client. I'd let the thread that read the headers of the request originally "die out" opening a bit more room for other clients.

..this might be too different from what HT currently does, or is. So maybe an option for me would be to add something that dispatches to this behavior internally (based on GET/POST parameters, I think) in HT. How close are you guys to finishing work on the branch by the way? I'm guessing it would make sense for me to work vs. the branch now.

Comet is used to push data from the server to the client like this by the way. Think of stock data in real time; using JS to update the HTML elements in the DOM on the client.

> With respect to this, the old and the new Hunchentoot should behave
> the same.  If they're not, that's probably an error.

Ok.

>> In the new HT this doesn't seem to happen (I think?), but the stream
>> is of a binary type. I was wondering -- how do I send text to this
>> stream?
> 
> Yes, this is new.  The rationale is that if you want maximum
> convenience and protection from errors, you just send content to
> Hunchentoot and let it take care of sending the right data to the
> client.  If you request a stream, you're likely doing this for
> performance reasons or because you want to do something special, so it
> seems right to give you the "raw" binary stream.  If you want to send
> text to this stream, wrap it with a flexi stream, see for example
> stream-direct-utf-8 here:
> 
>   http://bknr.net/trac/browser/trunk/thirdparty/hunchentoot/test/test.lisp

Thanks!

-- 
Lars Rune N?stdal
http://nostdal.org/



From hutch-lists at recursive.ca  Tue Jun 10 11:03:02 2008
From: hutch-lists at recursive.ca (Bob Hutchison)
Date: Tue, 10 Jun 2008 07:03:02 -0400
Subject: [hunchentoot-devel] Re: Current development
In-Reply-To: <g2lh70$82j$1@ger.gmane.org>
References: <u4p8lb050.fsf@agharta.de> <g2lh70$82j$1@ger.gmane.org>
Message-ID: <DC46B033-3481-4D33-B500-352440425732@recursive.ca>

Hi,

On 10-Jun-08, at 5:23 AM, Lars Rune N?stdal wrote:

> I'm working on a "comet" server. Hence the somewhat unusual way of  
> dealing with connections/streams.

That sounds interesting. How is it going?

How does what you're doing compare to what has been done here:

<http://groups.google.com/group/symbolicweb>

Anyway, please keep us updated on this list. I'm sure there are a  
bunch of us who are interested.

Cheers,
Bob

From edi at agharta.de  Tue Jun 10 11:39:28 2008
From: edi at agharta.de (Edi Weitz)
Date: Tue, 10 Jun 2008 13:39:28 +0200
Subject: [hunchentoot-devel] Re: Current development
In-Reply-To: <g2lkqk$kcl$1@ger.gmane.org> (Lars Rune
	=?iso-8859-1?q?N=F8stdal's?= message of "Tue,
	10 Jun 2008 12:25:22 +0200")
References: <u4p8lb050.fsf@agharta.de> <g2lh70$82j$1@ger.gmane.org>
	<uy75dljck.fsf@agharta.de> <g2lkqk$kcl$1@ger.gmane.org>
Message-ID: <utzg1ldsf.fsf@agharta.de>

On Tue, 10 Jun 2008 12:25:22 +0200, Lars Rune N?stdal <larsnostdal at gmail.com> wrote:

> I tried to save a closure with the stream (returned from
> send-headers) in it and I was intending to call it later when the
> server has something it wants to push to that client. I'd let the
> thread that read the headers of the request originally "die out"
> opening a bit more room for other clients.

That won't work with the current code.  Right now, the thread who
gives the stream to you (via SEND-HEADERS) "owns" the stream and if
you kill it, you can't just keep the stream.

You'll have to invent your own connection manager class for that.  The
exact plumbing of what happens when when requests are handled is still
in flux, but I hope the current state will give you an idea.

> ..this might be too different from what HT currently does, or is. So
> maybe an option for me would be to add something that dispatches to
> this behavior internally (based on GET/POST parameters, I think) in
> HT. How close are you guys to finishing work on the branch by the
> way? I'm guessing it would make sense for me to work vs. the branch
> now.

It would definitely make sense to do this vs. the branch.  Hans is
currently on vacation and I'm busy with other things, so work on the
branch has stalled a bit, but there should be more activity in the
next weeks.  No planned release date yet.


From larsnostdal at gmail.com  Tue Jun 10 19:00:01 2008
From: larsnostdal at gmail.com (=?UTF-8?B?TGFycyBSdW5lIE7DuHN0ZGFs?=)
Date: Tue, 10 Jun 2008 21:00:01 +0200
Subject: [hunchentoot-devel] Re: Current development
In-Reply-To: <DC46B033-3481-4D33-B500-352440425732@recursive.ca>
References: <u4p8lb050.fsf@agharta.de> <g2lh70$82j$1@ger.gmane.org>
	<DC46B033-3481-4D33-B500-352440425732@recursive.ca>
Message-ID: <g2mivi$4qs$1@ger.gmane.org>

Bob Hutchison wrote:
> Hi,
> 
> On 10-Jun-08, at 5:23 AM, Lars Rune N??stdal wrote:
> 
>> I'm working on a "comet" server. Hence the somewhat unusual way of 
>> dealing with connections/streams.
> 
> That sounds interesting. How is it going?

Hi,
It's progressing well and getting it to scale better is soon on the top of things to do.

> How does what you're doing compare to what has been done here:
> 
> <http://groups.google.com/group/symbolicweb>

Yeah, that's what I need this for. I've currently implemented Comet in that thing by setting the request/response thread to sleep (wait-condition), and it works great; but it will not scale because there is a limit to the amount of threads a server can have hanging around like that.

..so again that's why I need a "threadless" socket/stream from HT.. :)

> Anyway, please keep us updated on this list. I'm sure there are a bunch 
> of us who are interested.

Ok. Yeah, maybe a Comet module for HT would be of interest. I really hate promising things, but I might give it a try; I mean, attempt make it modularized and not hardwired into SymbolicWeb .... x)

-- 
Lars Rune N?stdal 
http://nostdal.org/



From luca at pca.it  Tue Jun 10 22:12:03 2008
From: luca at pca.it (Luca Capello)
Date: Wed, 11 Jun 2008 00:12:03 +0200
Subject: [hunchentoot-devel] Patches in the Hunchentoot Debian package
Message-ID: <87zlptvt1o.fsf@gismo.pca.it>

Hi all!

Please Cc: me, I'm not subscribed to the list and I'm posting from
Gmane.

The Debian package for Hunchentoot lacks three files because of
licensing issues:

- doc/hunchentoot.gif (as well as test/favicon.ico), because CC
    Attribution-ShareAlike (CC-by-sa) is considered non-free by Debian
    (see http://people.debian.org/~evan/ccsummary.html)

  FWIW, version 3.0 of the same license would be acceptable:

    http://wiki.debian.org/DFSGLicenses

- test/fz.jpg, since it misses any license bits

I didn't write to ask for a license change, but to inform you that the
included patches have been applied to the Debian package to cope with
these two problems:

- 01_replace-nonfree-logo-in-documentation.patch, the logo have been
  replaced by the word "[logo]" to preserve the link in doc/index.html

- 02_remove-nonfree-favicon-from-test-file.patch, any reference to the
  favicon has been simply removed

- 03_replace-Frank-Zappa-picture-in-test-file.patch, fz.jpg has been
  replaced by the Debian swirl logo (which should be present in all
  Debian installations).

FWIW, the Debian package is maintained in a git repository at:

  http://git.debian.org/?p=pkg-common-lisp/hunchentoot.git;a=summary

Thx, bye,
Gismo / Luca

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 01_replace-nonfree-logo-from-documentation.patch
Type: text/x-diff
Size: 442 bytes
Desc: replace the Debian non-free logo with the words	\"[logo]\" doc/index.html
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20080611/5dcd9e38/attachment.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 02_remove-nonfree-favicon-from-test-file.patch
Type: text/x-diff
Size: 868 bytes
Desc: remove any reference to test/favicon.ico in test/test.lisp
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20080611/5dcd9e38/attachment-0001.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 03_replace-Frank-Zappa-picture-in-test-file.patch
Type: text/x-diff
Size: 2716 bytes
Desc: replace test/fz.jpg with	/usr/share/pixmaps/debian-logo.png in test/test.lisp
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20080611/5dcd9e38/attachment-0002.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 314 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20080611/5dcd9e38/attachment.sig>

From bn at netfonds.no  Wed Jun 11 06:51:35 2008
From: bn at netfonds.no (=?ISO-8859-1?Q?Bj=F8rn_Nordb=F8?=)
Date: Wed, 11 Jun 2008 08:51:35 +0200
Subject: [hunchentoot-devel] Re: Current development
In-Reply-To: <g2mivi$4qs$1@ger.gmane.org>
References: <u4p8lb050.fsf@agharta.de> <g2lh70$82j$1@ger.gmane.org>
	<DC46B033-3481-4D33-B500-352440425732@recursive.ca>
	<g2mivi$4qs$1@ger.gmane.org>
Message-ID: <0F1634FC-92F7-4D92-BB27-F15CBB0E64F9@netfonds.no>


On 2008-06-10, at 9:00 PM, Lars Rune N?stdal wrote:
>
> Ok. Yeah, maybe a Comet module for HT would be of interest. I really  
> hate promising things, but I might give it a try; I mean, attempt  
> make it modularized and not hardwired into SymbolicWeb .... x)


It's interesting to read about your efforts as we discussed Comet
as a way to implement real time streaming to our Ajaxy mobile
application yesterday.  In fact I started writing a Comet module
for it almost a year ago (only a naive test), but the interest
vaned as the only mobile device that worked with it was the
iPhone.

But I was just thinking of looking at it again as the situation
on the client side may have improved since then.  And, of course,
the iPhone is finally coming to Norway.

Anyway, my point is that since there are two developers in Norway
that have interest in Hunchentoot/Comet, there has to be hundreds
if not thousands! worldwide. :-)

-- 
Bj?rn Nordb?




From tjg at pentaside.org  Wed Jun 11 09:20:06 2008
From: tjg at pentaside.org (Tayssir John Gabbour)
Date: Wed, 11 Jun 2008 11:20:06 +0200
Subject: [hunchentoot-devel] Speed of binary uploads
Message-ID: <484F98C6.8020307@pentaside.org>

Hi,

Does anyone have speed problems uploading big binary files to 
Hunchentoot? (I just made a clean install, and it's still slow. I've 
tested using both drakma:http-request and HTML forms.)

For a 60 meg file -- even on the same machine -- it takes about 90 
seconds. SCP does it in 10 seconds. Here is my code:


;; Omitting handler, as it's called after the file is received in the
;; temp directory.

(defun start-webserver ()
   (stop-webserver)
   (setf *catch-errors-p* nil)
   (setf *webserver* (start-server :mod-lisp-p t :port 3004)))


(defun upload-form ()
   (cl-who:with-html-output-to-string (*standard-output*)
       (:form :action "upload"
              :enctype "multipart/form-data"
              :method :post
              "File to send"
              (:input :type :file :name "upload" :size 40)
              (:input :type :submit :value "send"))))




If no one else has this problem, I'll test further where my problem lies...


Thanks!
Tayssir


From edi at agharta.de  Wed Jun 11 09:31:55 2008
From: edi at agharta.de (Edi Weitz)
Date: Wed, 11 Jun 2008 11:31:55 +0200
Subject: [hunchentoot-devel] Speed of binary uploads
In-Reply-To: <484F98C6.8020307@pentaside.org> (Tayssir John Gabbour's
	message of "Wed, 11 Jun 2008 11:20:06 +0200")
References: <484F98C6.8020307@pentaside.org>
Message-ID: <uwskwz59w.fsf@agharta.de>

Hi Tayssir,

On Wed, 11 Jun 2008 11:20:06 +0200, Tayssir John Gabbour <tjg at pentaside.org> wrote:

> Does anyone have speed problems uploading big binary files to
> Hunchentoot? (I just made a clean install, and it's still slow. I've
> tested using both drakma:http-request and HTML forms.)
>
> For a 60 meg file -- even on the same machine -- it takes about 90
> seconds. SCP does it in 10 seconds. Here is my code:

Is that with the development version?  All performance-related issues
should be discussed with respect to the dev version as this is one of
the areas it is supposed to address.  See here

  http://bknr.net/trac/browser/ediware

and the recent postings to this list.  In particular, you need to
update /all/ libraries listed there to test it.

Having said that, I suspect that file uploads might not be
significantly faster than with the release version yet.  Speeding them
up will probably involve looking at and maybe replacing the RFC2388
library.  This is also on my todo list but doesn't have such a high
priority right now.

HTH,
Edi.


From larsnostdal at gmail.com  Wed Jun 11 12:35:16 2008
From: larsnostdal at gmail.com (=?UTF-8?B?TGFycyBSdW5lIE7DuHN0ZGFs?=)
Date: Wed, 11 Jun 2008 14:35:16 +0200
Subject: [hunchentoot-devel] Re: Current development
In-Reply-To: <0F1634FC-92F7-4D92-BB27-F15CBB0E64F9@netfonds.no>
References: <u4p8lb050.fsf@agharta.de>
	<g2lh70$82j$1@ger.gmane.org>	<DC46B033-3481-4D33-B500-352440425732@recursive.ca>	<g2mivi$4qs$1@ger.gmane.org>
	<0F1634FC-92F7-4D92-BB27-F15CBB0E64F9@netfonds.no>
Message-ID: <g2ogq5$knm$1@ger.gmane.org>

Bj?rn Nordb? wrote:
> 
> On 2008-06-10, at 9:00 PM, Lars Rune N?stdal wrote:
>>
>> Ok. Yeah, maybe a Comet module for HT would be of interest. I really 
>> hate promising things, but I might give it a try; I mean, attempt make 
>> it modularized and not hardwired into SymbolicWeb .... x)
> 
> 
> It's interesting to read about your efforts as we discussed Comet
> as a way to implement real time streaming to our Ajaxy mobile
> application yesterday.  In fact I started writing a Comet module
> for it almost a year ago (only a naive test), but the interest
> vaned as the only mobile device that worked with it was the
> iPhone.
> 
> But I was just thinking of looking at it again as the situation
> on the client side may have improved since then.  And, of course,
> the iPhone is finally coming to Norway.
> 
> Anyway, my point is that since there are two developers in Norway
> that have interest in Hunchentoot/Comet, there has to be hundreds
> if not thousands! worldwide. :-)
> 
> --Bj?rn Nordb?
> 
> 

..hehe x)

Ok, way early, but something like this:
  http://paste.lisp.org/display/62069

It works, but it's not finished. .. I'll document it later and provide a small example (that depends on HT only). There are really just two new exported symbols; COMET-SERVER and WITH-DELAYED-RESPONSE.

Instead of using START-SERVER one have got to do:

  (tbnl::start (make-instance 'tbnl:comet-server :port 6001))


..the reason for this is that it seems START-SERVER doesn't accept a custom server designator at the moment.

The other exported symbol, WITH-DELAYED-RESPONSE, works something like this from inside a normal handler function:

  (with-delayed-response (stream *comet-delay-in-secs* closure
                                 (setf (comet-closure-of session) closure))
    (if (comet-message-exists-p session)
        (princ (comet-message-of session) stream)
        (princ "no message - but keep on polling, mr. client!" stream)))


Then something like this:

  (defun say (msg)
    (push msg (comet-message-of session))
    (when (comet-closure-of session)
       (funcall (comet-closure-of session))))


..ok, now I gotta start dealing with the connections proper, and logging etc.

-- 
Lars Rune N?stdal
http://nostdal.org/



From edi at agharta.de  Wed Jun 11 12:48:20 2008
From: edi at agharta.de (Edi Weitz)
Date: Wed, 11 Jun 2008 14:48:20 +0200
Subject: [hunchentoot-devel] Re: Current development
In-Reply-To: <g2ogq5$knm$1@ger.gmane.org> (Lars Rune
	=?iso-8859-1?q?N=F8stdal's?= message of "Wed,
	11 Jun 2008 14:35:16 +0200")
References: <u4p8lb050.fsf@agharta.de> <g2lh70$82j$1@ger.gmane.org>
	<DC46B033-3481-4D33-B500-352440425732@recursive.ca>
	<g2mivi$4qs$1@ger.gmane.org>
	<0F1634FC-92F7-4D92-BB27-F15CBB0E64F9@netfonds.no>
	<g2ogq5$knm$1@ger.gmane.org>
Message-ID: <uskvkyw6j.fsf@agharta.de>

On Wed, 11 Jun 2008 14:35:16 +0200, Lars Rune N?stdal <larsnostdal at gmail.com> wrote:

> ..the reason for this is that it seems START-SERVER doesn't accept a
> custom server designator at the moment.

This will be added before we make a release.  It is not fully clear
yet how the final API will look like, though.


From larsnostdal at gmail.com  Wed Jun 11 14:55:57 2008
From: larsnostdal at gmail.com (=?UTF-8?B?TGFycyBSdW5lIE7DuHN0ZGFs?=)
Date: Wed, 11 Jun 2008 16:55:57 +0200
Subject: [hunchentoot-devel] Re: Current development
In-Reply-To: <g2ogq5$knm$1@ger.gmane.org>
References: <u4p8lb050.fsf@agharta.de>	<g2lh70$82j$1@ger.gmane.org>	<DC46B033-3481-4D33-B500-352440425732@recursive.ca>	<g2mivi$4qs$1@ger.gmane.org>	<0F1634FC-92F7-4D92-BB27-F15CBB0E64F9@netfonds.no>
	<g2ogq5$knm$1@ger.gmane.org>
Message-ID: <g2op1t$kk7$1@ger.gmane.org>

Lars Rune N?stdal wrote:
> Bj??rn Nordb?? wrote:
>>
>> On 2008-06-10, at 9:00 PM, Lars Rune N??stdal wrote:
>>>
>>> Ok. Yeah, maybe a Comet module for HT would be of interest. I really 
>>> hate promising things, but I might give it a try; I mean, attempt 
>>> make it modularized and not hardwired into SymbolicWeb .... x)
>>
>>
>> It's interesting to read about your efforts as we discussed Comet
>> as a way to implement real time streaming to our Ajaxy mobile
>> application yesterday.  In fact I started writing a Comet module
>> for it almost a year ago (only a naive test), but the interest
>> vaned as the only mobile device that worked with it was the
>> iPhone.
>>
>> But I was just thinking of looking at it again as the situation
>> on the client side may have improved since then.  And, of course,
>> the iPhone is finally coming to Norway.
>>
>> Anyway, my point is that since there are two developers in Norway
>> that have interest in Hunchentoot/Comet, there has to be hundreds
>> if not thousands! worldwide. :-)
>>
>> --Bj??rn Nordb??
>>
>>
> 
> ..hehe x)
> 
> Ok, way early, but something like this:
> http://paste.lisp.org/display/62069 


..yeah, bit too early. I'll try again later, but the general idea is something like what's seen there..

..sleep now..

-- 
Lars Rune N?stdal
http://nostdal.org/



From larsnostdal at gmail.com  Sat Jun 14 05:21:05 2008
From: larsnostdal at gmail.com (=?UTF-8?B?TGFycyBSdW5lIE7DuHN0ZGFs?=)
Date: Sat, 14 Jun 2008 07:21:05 +0200
Subject: [hunchentoot-devel] Re: Current development
In-Reply-To: <g2op1t$kk7$1@ger.gmane.org>
References: <u4p8lb050.fsf@agharta.de>	<g2lh70$82j$1@ger.gmane.org>	<DC46B033-3481-4D33-B500-352440425732@recursive.ca>	<g2mivi$4qs$1@ger.gmane.org>	<0F1634FC-92F7-4D92-BB27-F15CBB0E64F9@netfonds.no>	<g2ogq5$knm$1@ger.gmane.org>
	<g2op1t$kk7$1@ger.gmane.org>
Message-ID: <g2vkg0$dqu$1@ger.gmane.org>

Lars Rune N?stdal wrote:
> Lars Rune N??stdal wrote:
>> Bj????rn Nordb???? wrote:
>>>
>>> On 2008-06-10, at 9:00 PM, Lars Rune N????stdal wrote:
>>>>
>>>> Ok. Yeah, maybe a Comet module for HT would be of interest. I really 
>>>> hate promising things, but I might give it a try; I mean, attempt 
>>>> make it modularized and not hardwired into SymbolicWeb .... x)
>>>
>>>
>>> It's interesting to read about your efforts as we discussed Comet
>>> as a way to implement real time streaming to our Ajaxy mobile
>>> application yesterday.  In fact I started writing a Comet module
>>> for it almost a year ago (only a naive test), but the interest
>>> vaned as the only mobile device that worked with it was the
>>> iPhone.
>>>
>>> But I was just thinking of looking at it again as the situation
>>> on the client side may have improved since then.  And, of course,
>>> the iPhone is finally coming to Norway.
>>>
>>> Anyway, my point is that since there are two developers in Norway
>>> that have interest in Hunchentoot/Comet, there has to be hundreds
>>> if not thousands! worldwide. :-)
>>>
>>> --Bj????rn Nordb????
>>>
>>>
>>
>> ..hehe x)
>>
>> Ok, way early, but something like this:
>> http://paste.lisp.org/display/62069 
> 
> 
> ..yeah, bit too early. I'll try again later, but the general idea is 
> something like what's seen there..
> 
> ..sleep now..
> 

.. Ok, back again x) .. I gave it a try but I'll stick with the old thread + wait-condition method for now. It works well; the only problem is that it does not scale, so I'll work on something else for SW than scalability for a while.

There are too many changes needed to pull this off properly and I think it'll basically end up a complete rewrite of HT instead of just an addon/module for it. I can try to describe some of the problems even though many of you are probably already aware of some of them.

A major problem is global variables. I suggest that instead of having things like *REPLY* *REQUEST* *SERVER* and *HUNCHENTOOT-STREAM*, a concept of or class ROUND-TRIP is added:

  (defclass round-trip ()
   ((request)
    (response)
    (socket)
    (stream)
    (server)
    (session)))


..and that for, perhaps, backward compatibility things like this would do:

  (define-symbol-macro *session* (session-of *round-trip*))


This would "close over" a single round-trip cycle (request->response) and maintain everything in one place so it can be passed around easily ("response is to be delayed, thus end this thread and pass it to another thread for execution later!").

Also, this means handling of a round-trip cycle cannot be hardcoded into a single function/method or into a single path of execution (a single thread). Using things like UNWIND-PROTECT makes the path of execution static; "when thread ends close the stream" (but we, well I, don't want this!). 

I think things needs to be more split up for this to happen; this is hard to get just right.

I recall removal of globals mentioned on this list for the new HT, and to avoid stepping on peoples toes and wasting time I'll wait around a bit. It also seems things are moving from DEFUN to DEFMETHOD which would enable things to be more split up by the user.

-- 
Lars Rune N?stdal
http://nostdal.org/



From edi at agharta.de  Sat Jun 14 14:04:28 2008
From: edi at agharta.de (Edi Weitz)
Date: Sat, 14 Jun 2008 16:04:28 +0200
Subject: [hunchentoot-devel] Re: Current development
In-Reply-To: <g2vkg0$dqu$1@ger.gmane.org> (Lars Rune
	=?iso-8859-1?q?N=F8stdal's?= message of "Sat,
	14 Jun 2008 07:21:05 +0200")
References: <u4p8lb050.fsf@agharta.de> <g2lh70$82j$1@ger.gmane.org>
	<DC46B033-3481-4D33-B500-352440425732@recursive.ca>
	<g2mivi$4qs$1@ger.gmane.org>
	<0F1634FC-92F7-4D92-BB27-F15CBB0E64F9@netfonds.no>
	<g2ogq5$knm$1@ger.gmane.org> <g2op1t$kk7$1@ger.gmane.org>
	<g2vkg0$dqu$1@ger.gmane.org>
Message-ID: <u4p7wi043.fsf@agharta.de>

On Sat, 14 Jun 2008 07:21:05 +0200, Lars Rune N?stdal <larsnostdal at gmail.com> wrote:

> A major problem is global variables.

As you already mentioned, this will be partly addressed by upcoming
changes.  Still, I'd be interested in how far this is really a "major
problem" when you try to implement certain things.  You aren't forced
to use the special variables, are you?

> Also, this means handling of a round-trip cycle cannot be hardcoded
> into a single function/method or into a single path of execution (a
> single thread). Using things like UNWIND-PROTECT makes the path of
> execution static; "when thread ends close the stream" (but we, well
> I, don't want this!).

The goal of the current development obviously is to make Hunchentoot
more flexible and at the same time to give its users more rope to hang
themselves.  In the end, it will still be a web server, though, with
an eye on simplicity and backwards compatibility, it won't become an
all singing and dancing General Problem Solver.  I hope you won't be
disappointed.

(Just out of curiosity, are there general purpose web servers out
there where one single request is not handled within one
thread/process?  I'm aware that Apache for example has a pretty
sophisticated model of providing different ways of hooking into the
request handling architecture.  Still, I think, the thread that
accepts the request will always be the one which is in charge of
sending the reply and cleaning up, or am I wrong?)


From hutch-lists at recursive.ca  Sat Jun 14 15:11:52 2008
From: hutch-lists at recursive.ca (Bob Hutchison)
Date: Sat, 14 Jun 2008 11:11:52 -0400
Subject: [hunchentoot-devel] Re: Current development
In-Reply-To: <u4p7wi043.fsf@agharta.de>
References: <u4p8lb050.fsf@agharta.de> <g2lh70$82j$1@ger.gmane.org>
	<DC46B033-3481-4D33-B500-352440425732@recursive.ca>
	<g2mivi$4qs$1@ger.gmane.org>
	<0F1634FC-92F7-4D92-BB27-F15CBB0E64F9@netfonds.no>
	<g2ogq5$knm$1@ger.gmane.org> <g2op1t$kk7$1@ger.gmane.org>
	<g2vkg0$dqu$1@ger.gmane.org> <u4p7wi043.fsf@agharta.de>
Message-ID: <950FDBF8-7FC5-47B9-BB97-4906EAB245B6@recursive.ca>


On 14-Jun-08, at 10:04 AM, Edi Weitz wrote:

> On Sat, 14 Jun 2008 07:21:05 +0200, Lars Rune N?stdal <larsnostdal at gmail.com 
> > wrote:
>
> The goal of the current development obviously is to make Hunchentoot
> more flexible and at the same time to give its users more rope to hang
> themselves.  In the end, it will still be a web server, though, with
> an eye on simplicity and backwards compatibility, it won't become an
> all singing and dancing General Problem Solver.  I hope you won't be
> disappointed.

Edi, you've set the expectations :-)

>
>
> (Just out of curiosity, are there general purpose web servers out
> there where one single request is not handled within one
> thread/process?  I'm aware that Apache for example has a pretty
> sophisticated model of providing different ways of hooking into the
> request handling architecture.  Still, I think, the thread that
> accepts the request will always be the one which is in charge of
> sending the reply and cleaning up, or am I wrong?)

My limited understanding of what they are doing is to separate socket  
handling from the thread that does the work (in increasingly  
sophisticated ways). So when a request comes a thread is assigned to  
it, handles the request and returns to the pool of available threads.  
The socket isn't necessarily closed (does HT handle keep-alive?) and  
is somehow named if it is kept open. If you tie this in with threads/ 
processes that are independent of the request-handling task, you can  
imagine one of these threads asking for a specific socket (or maybe a  
bunch of them) that is still open and shoving something down the  
socket/s, still not closing it/them. This also works with the new  
fangled event driven server stuff. Apache, jetty, tomcat, and a bunch  
of python, perl, and even a plugin for Rails (and <http://groups.google.com/group/symbolicweb 
 > for lisp). There are problems with doing this using long lived HTTP  
connections (e.g. firewalls), but people are doing it, so...

I didn't really take this too seriously until someone managed to  
comfortably handle many thousands (20000??) concurrent comet  
connections (the article went through what was done to achieve this  
number). It was nicely documented in an article, that, naturally, I  
can't find at the moment. I think this article might talking about the  
same thing, but it is certainly talking of 20000 connections, but it  
is mostly just reporting it:

<http://cometdaily.com/2008/01/07/20000-reasons-that-comet-scales/>.

This is possible useful:

<http://ajaxexperience.techtarget.com/assets/documents/Carter_Michael_ScalableComet.pdf 
 >

Cheers,
Bob


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


From rsynnott at gmail.com  Sat Jun 14 15:23:27 2008
From: rsynnott at gmail.com (Robert Synnott)
Date: Sat, 14 Jun 2008 16:23:27 +0100
Subject: [hunchentoot-devel] Re: Current development
In-Reply-To: <950FDBF8-7FC5-47B9-BB97-4906EAB245B6@recursive.ca>
References: <u4p8lb050.fsf@agharta.de> <g2lh70$82j$1@ger.gmane.org>
	<DC46B033-3481-4D33-B500-352440425732@recursive.ca>
	<g2mivi$4qs$1@ger.gmane.org>
	<0F1634FC-92F7-4D92-BB27-F15CBB0E64F9@netfonds.no>
	<g2ogq5$knm$1@ger.gmane.org> <g2op1t$kk7$1@ger.gmane.org>
	<g2vkg0$dqu$1@ger.gmane.org> <u4p7wi043.fsf@agharta.de>
	<950FDBF8-7FC5-47B9-BB97-4906EAB245B6@recursive.ca>
Message-ID: <24f203480806140823s6c03de64j6cad0ae6ab74a037@mail.gmail.com>

2008/6/14 Bob Hutchison <hutch-lists at recursive.ca>:
>
...
>
> I didn't really take this too seriously until someone managed to comfortably
> handle many thousands (20000??) concurrent comet connections (the article
> went through what was done to achieve this number). It was nicely documented
> in an article, that, naturally, I can't find at the moment. I think this
> article might talking about the same thing, but it is certainly talking of
> 20000 connections, but it is mostly just reporting it:
>
> <http://cometdaily.com/2008/01/07/20000-reasons-that-comet-scales/>.
>...

I think I've seen this; if it's the same article, it was done in
Erlang, using that language's lightweight processes. As such, it's not
using quite the same techniques that any Hunchentoot implementation
would.
Rob


From edi at agharta.de  Sat Jun 14 16:53:22 2008
From: edi at agharta.de (Edi Weitz)
Date: Sat, 14 Jun 2008 18:53:22 +0200
Subject: [hunchentoot-devel] Re: Current development
In-Reply-To: <950FDBF8-7FC5-47B9-BB97-4906EAB245B6@recursive.ca> (Bob
	Hutchison's message of "Sat, 14 Jun 2008 11:11:52 -0400")
References: <u4p8lb050.fsf@agharta.de> <g2lh70$82j$1@ger.gmane.org>
	<DC46B033-3481-4D33-B500-352440425732@recursive.ca>
	<g2mivi$4qs$1@ger.gmane.org>
	<0F1634FC-92F7-4D92-BB27-F15CBB0E64F9@netfonds.no>
	<g2ogq5$knm$1@ger.gmane.org> <g2op1t$kk7$1@ger.gmane.org>
	<g2vkg0$dqu$1@ger.gmane.org> <u4p7wi043.fsf@agharta.de>
	<950FDBF8-7FC5-47B9-BB97-4906EAB245B6@recursive.ca>
Message-ID: <uzlpogdq5.fsf@agharta.de>

On Sat, 14 Jun 2008 11:11:52 -0400, Bob Hutchison <hutch-lists at recursive.ca> wrote:

> My limited understanding of what they are doing

With "they" you mean Apache?

> does HT handle keep-alive?

Yes.


From hutch-lists at recursive.ca  Sat Jun 14 17:48:35 2008
From: hutch-lists at recursive.ca (Bob Hutchison)
Date: Sat, 14 Jun 2008 13:48:35 -0400
Subject: [hunchentoot-devel] Re: Current development
In-Reply-To: <uzlpogdq5.fsf@agharta.de>
References: <u4p8lb050.fsf@agharta.de> <g2lh70$82j$1@ger.gmane.org>
	<DC46B033-3481-4D33-B500-352440425732@recursive.ca>
	<g2mivi$4qs$1@ger.gmane.org>
	<0F1634FC-92F7-4D92-BB27-F15CBB0E64F9@netfonds.no>
	<g2ogq5$knm$1@ger.gmane.org> <g2op1t$kk7$1@ger.gmane.org>
	<g2vkg0$dqu$1@ger.gmane.org> <u4p7wi043.fsf@agharta.de>
	<950FDBF8-7FC5-47B9-BB97-4906EAB245B6@recursive.ca>
	<uzlpogdq5.fsf@agharta.de>
Message-ID: <8C7DCBB4-ED49-4049-B460-55F589A77771@recursive.ca>


On 14-Jun-08, at 12:53 PM, Edi Weitz wrote:

> On Sat, 14 Jun 2008 11:11:52 -0400, Bob Hutchison <hutch-lists at recursive.ca 
> > wrote:
>
>> My limited understanding of what they are doing
>
> With "they" you mean Apache?

No, I meant every server/group/person who is trying to do something  
like comet. That includes Apache, or possibly some groups contributing  
modules to Apache, or both.

>
>
>> does HT handle keep-alive?
>
> Yes.

I'm not sure what all Lars needs here, but it at a first pass, if you  
keep those sockets alive and name them and so allowing some  
independent thread or event handler to find the socket and use it  
again... Well, as I said, I don't know what Lars needs, but I think I  
could do some fun stuff with that capability.

Cheers,
Bob

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



From larsnostdal at gmail.com  Sat Jun 14 19:33:40 2008
From: larsnostdal at gmail.com (=?ISO-8859-1?Q?Lars_Rune_N=F8stdal?=)
Date: Sat, 14 Jun 2008 21:33:40 +0200
Subject: [hunchentoot-devel] Re: Current development
In-Reply-To: <u4p7wi043.fsf@agharta.de>
References: <u4p8lb050.fsf@agharta.de>
	<g2lh70$82j$1@ger.gmane.org>	<DC46B033-3481-4D33-B500-352440425732@recursive.ca>	<g2mivi$4qs$1@ger.gmane.org>	<0F1634FC-92F7-4D92-BB27-F15CBB0E64F9@netfonds.no>	<g2ogq5$knm$1@ger.gmane.org>
	<g2op1t$kk7$1@ger.gmane.org>	<g2vkg0$dqu$1@ger.gmane.org>
	<u4p7wi043.fsf@agharta.de>
Message-ID: <g316ee$6bu$1@ger.gmane.org>

Edi Weitz wrote:
> On Sat, 14 Jun 2008 07:21:05 +0200, Lars Rune N?stdal <larsnostdal at gmail.com> wrote:
> 
>> A major problem is global variables.
> 
> As you already mentioned, this will be partly addressed by upcoming
> changes.  Still, I'd be interested in how far this is really a "major
> problem" when you try to implement certain things.  You aren't forced
> to use the special variables, are you?

No, I guess not -- maybe not. It starts with a socket/stream at the
connection-manager end, and functions seem to accept
&optional (reply *reply*) etc. .. so I can build on that from the
lowest levels and up, I think.

I'll give this a new try a bit later and go about it a bit slower and
build something from the ground up instead. I figured I could hack this
together quickly with the parts that where there already by moving
them around and splitting them up a bit, but maybe that's not such a
good idea currently. It just gets more complicated that way I think.

..I should wait a bit and see what happens though..

I still have a feeling the global variables should be removed or, that
is, gathered together into a "single blob" so the whole concept
of a request-response cycle (round-trip) can be passed around easily
if the user really needs to do this.

I know global vars aren't "dangerous" in Lisp like in other languages
when they are bound (LET) within a single thread where the execution
path is predefined or stays within a single thread; that's not what I
mean =) .. but in this case the bindings or data needs to be accessed
from  multiple threads (or well, moved to a new thread) as the cycle
"walks forward".

But, OK, never mind .. globals vars are being addressed - and/or I can
just not used them for my stuff; right. It will work out.


>> Also, this means handling of a round-trip cycle cannot be hardcoded
>> into a single function/method or into a single path of execution (a
>> single thread). Using things like UNWIND-PROTECT makes the path of
>> execution static; "when thread ends close the stream" (but we, well
>> I, don't want this!).
> 
> The goal of the current development obviously is to make Hunchentoot
> more flexible and at the same time to give its users more rope to hang
> themselves.  In the end, it will still be a web server, though, with
> an eye on simplicity and backwards compatibility, it won't become an
> all singing and dancing General Problem Solver.  I hope you won't be
> disappointed.

Yeah, I don't think I'll be disappointed but it would be great not
having to write huge parts from scratch like mentioned above even
though it would actually be possible to do so.

If things are split up and work more on their own not depending on
different context bits (global variables, let-bindings etc.) at the
same time this will enable code-bits to be shared between multiple
server backends, modules or connection-managers, I think/hope.


> (Just out of curiosity, are there general purpose web servers out
> there where one single request is not handled within one
> thread/process?  I'm aware that Apache for example has a pretty
> sophisticated model of providing different ways of hooking into the
> request handling architecture.  Still, I think, the thread that
> accepts the request will always be the one which is in charge of
> sending the reply and cleaning up, or am I wrong?)

The thread cannot wait around for the server to have anything to send
as a response; it will not scale in any Lisp I know of.

-- 
Lars Rune N?stdal
http://nostdal.org/



From larsnostdal at gmail.com  Sat Jun 14 19:53:24 2008
From: larsnostdal at gmail.com (=?ISO-8859-1?Q?Lars_Rune_N=F8stdal?=)
Date: Sat, 14 Jun 2008 21:53:24 +0200
Subject: [hunchentoot-devel] Re: Current development
In-Reply-To: <950FDBF8-7FC5-47B9-BB97-4906EAB245B6@recursive.ca>
References: <u4p8lb050.fsf@agharta.de>
	<g2lh70$82j$1@ger.gmane.org>	<DC46B033-3481-4D33-B500-352440425732@recursive.ca>	<g2mivi$4qs$1@ger.gmane.org>	<0F1634FC-92F7-4D92-BB27-F15CBB0E64F9@netfonds.no>	<g2ogq5$knm$1@ger.gmane.org>
	<g2op1t$kk7$1@ger.gmane.org>	<g2vkg0$dqu$1@ger.gmane.org>
	<u4p7wi043.fsf@agharta.de>
	<950FDBF8-7FC5-47B9-BB97-4906EAB245B6@recursive.ca>
Message-ID: <g317je$9a7$1@ger.gmane.org>

Bob Hutchison wrote:
> 
> On 14-Jun-08, at 10:04 AM, Edi Weitz wrote:
> 
>> On Sat, 14 Jun 2008 07:21:05 +0200, Lars Rune N?stdal 
>> <larsnostdal at gmail.com> wrote:
>>
>> The goal of the current development obviously is to make Hunchentoot
>> more flexible and at the same time to give its users more rope to hang
>> themselves.  In the end, it will still be a web server, though, with
>> an eye on simplicity and backwards compatibility, it won't become an
>> all singing and dancing General Problem Solver.  I hope you won't be
>> disappointed.
> 
> Edi, you've set the expectations :-)
> 
>>
>>
>> (Just out of curiosity, are there general purpose web servers out
>> there where one single request is not handled within one
>> thread/process?  I'm aware that Apache for example has a pretty
>> sophisticated model of providing different ways of hooking into the
>> request handling architecture.  Still, I think, the thread that
>> accepts the request will always be the one which is in charge of
>> sending the reply and cleaning up, or am I wrong?)
> 
> My limited understanding of what they are doing is to separate socket 
> handling from the thread that does the work (in increasingly 
> sophisticated ways). So when a request comes a thread is assigned to it, 
> handles the request and returns to the pool of available threads. The 
> socket isn't necessarily closed (does HT handle keep-alive?) and is 
> somehow named if it is kept open. If you tie this in with 
> threads/processes that are independent of the request-handling task, you 
> can imagine one of these threads asking for a specific socket (or maybe 
> a bunch of them) that is still open and shoving something down the 
> socket/s, still not closing it/them. This also works with the new 
> fangled event driven server stuff. Apache, jetty, tomcat, and a bunch of 
> python, perl, and even a plugin for Rails (and 
> <http://groups.google.com/group/symbolicweb> for lisp). There are 
> problems with doing this using long lived HTTP connections (e.g. 
> firewalls), but people are doing it, so...

Just a quick note that reducing the timeout of the comet-response (the
empty one) works in these cases. I've confirmed this with more than one
corporate firewall to the surprise of people expecting any networked
application in similar style of something SW'ish to fail. :)

... I might add some heuristics that does some automatic adjusting and
detecting on "boot-up time" for the comet timeout later ...

-- 
Lars Rune N?stdal
http://nostdal.org/



From luca at pca.it  Sun Jun 15 19:16:36 2008
From: luca at pca.it (Luca Capello)
Date: Sun, 15 Jun 2008 21:16:36 +0200
Subject: [hunchentoot-devel] Patches in the Hunchentoot Debian package
References: <87zlptvt1o.fsf@gismo.pca.it>
Message-ID: <87wskqfqzv.fsf@gismo.pca.it>

Hi all!

On Wed, 11 Jun 2008 00:12:03 +0200, Luca Capello wrote:
> Please Cc: me, I'm not subscribed to the list and I'm posting from
> Gmane.

Still valid :-)

> The Debian package for Hunchentoot lacks three files because of
> licensing issues:
>
> - doc/hunchentoot.gif (as well as test/favicon.ico), because CC
>     Attribution-ShareAlike (CC-by-sa) is considered non-free by Debian
>     (see http://people.debian.org/~evan/ccsummary.html)
>
>   FWIW, version 3.0 of the same license would be acceptable:
>
>     http://wiki.debian.org/DFSGLicenses

After my post, Uwe von Loh relicensed the Hunchentoot logo under
CC-by-sa 3.0 US, which means that now Debian can distribute it as well.
Many thanks to Uwe!

> - 01_replace-nonfree-logo-in-documentation.patch, the logo have been
>   replaced by the word "[logo]" to preserve the link in doc/index.html
>
> - 02_remove-nonfree-favicon-from-test-file.patch, any reference to the
>   favicon has been simply removed

For the reason above, these two patches are no more included in the
Debian package, which is actually waiting in the Debian NEW queue [1]
because of the name change for the binary package [2].

Thx, bye,
Gismo / Luca

Footnotes: 
[1] http://ftp-master.debian.org/new.html
[2] http://lists.alioth.debian.org/pipermail/pkg-common-lisp-devel/2008-June/000678.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 314 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20080615/dec877a5/attachment.sig>

From wade.humeniuk at gmail.com  Mon Jun 16 04:52:15 2008
From: wade.humeniuk at gmail.com (Wade Humeniuk)
Date: Sun, 15 Jun 2008 22:52:15 -0600
Subject: [hunchentoot-devel] Clozure CL HUNCHENTOOT-TEST Error
Message-ID: <4a8bfaea0806152152i4abaf4a1l8566f136f25cac07@mail.gmail.com>

I am using Clozure CL 1.2 rc1.2 with Hunchentoot.  The
hunchentoot-test pages that come with the install
are not working completely.  I had the to modify the test code in
test.lisp to get a backtrace of what was
happening.  stream-direct-utf-8 is throwing an error and no content is
coming back.

(defvar *htest-debug-stream* nil)

(defun stream-direct-utf-8 ()
  (handler-bind ((error (lambda (c)
			  (describe c *htest-debug-stream*)
			  (format *htest-debug-stream* "~A" (hunchentoot:get-backtrace c)))))
    (setf (content-type) "text/html; charset=utf-8")
    (let ((stream (send-headers)))
      (setf (flex:flexi-stream-external-format stream) *utf-8*)
      (with-open-file (in (merge-pathnames "UTF-8-demo.html" *this-file*)
			  :element-type 'flex:octet)
	(setq in (flex:make-flexi-stream in :external-format *utf-8*))
	(loop for line = (read-line in nil nil)
	   while line
	   do (write-line line stream))))))

and modifying chunga::write-chunk to..

(defmethod write-chunk ((stream chunked-output-stream) sequence
                        &key (start 0)
                             (end (length sequence)))
  "Writes the contents of SEQUENCE from START to END to the
underlying stream of STREAM as one chunk."
  (let ((output-stream (chunked-stream-output-stream stream)))
    (describe output-stream hunchentoot-test::*htest-debug-stream*)
    ;; chunk size
    (format output-stream "~X" (- end start))
    ;; CRLF
    (write-string #.(format nil "~C~C" #\Return #\Linefeed) output-stream)
    ;; data
    #+:clisp (setf (flexi-stream-element-type output-stream) 'octet)
    (write-sequence sequence output-stream :start start :end end)
    #+:clisp (setf (flexi-stream-element-type output-stream) 'character)
    ;; CRLF
    (write-string #.(format nil "~C~C" #\Return #\Linefeed) output-stream)))



Visting the page /hunchentoot/test/utf8-character.txt produces the output below.
As far as I can tell from looking at the code there should be no instance of
EXTERNAL-FORMAT since there is no method FLEXI-STREAMS::ENCODING-FACTOR
for it  (only subclasses of EXTERNAL-FORMAT).  I have pretty well banged my head
looking at the code in flexi-streams and chunga trying to determine the problem.
This works fine for SBCL, and I see no conditional code for CCL that
might explain the
problem.

Wade

CL-USER> (hunchentoot:start-server :port 4242)
#<HUNCHENTOOT::SERVER #x3000426BF81D>
CL-USER> (setf hunchentoot-test::*htest-debug-stream* *standard-output*)
#<SWANK-BACKEND::SLIME-OUTPUT-STREAM #x300040E2FC1D>
#<SIMPLE-ERROR #x30004274A50D>
Class: #<STANDARD-CLASS SIMPLE-ERROR>
Wrapper: #<CLASS-WRAPPER  #x3000404AC86D>
Instance slots
CCL::FORMAT-CONTROL: "No applicable method for args:~% ~s~% to ~s"
CCL::FORMAT-ARGUMENTS: ((#<EXTERNAL-FORMAT (:ISO-8859-1
                                            :EOL-STYLE
                                            :LF) #x30004122DA1D>)
                        #<STANDARD-GENERIC-FUNCTION
FLEXI-STREAMS::ENCODING-FACTOR #x300040FACA3F>)


BACKTRACE--->>>>>>

 (7FC8F700D0B8) : 0 (GET-BACKTRACE #<SIMPLE-ERROR #x30004274A50D>) 285
 (7FC8F700D120) : 1 (FUNCALL #'#<(:INTERNAL
HUNCHENTOOT-TEST::STREAM-DIRECT-UTF-8)> #<SIMPLE-ERROR
#x30004274A50D>) 173
 (7FC8F700D140) : 2 (SIGNAL #<SIMPLE-ERROR #x30004274A50D> [...]) 997
 (7FC8F700D198) : 3 (%ERROR #<SIMPLE-ERROR #x30004274A50D> NIL
17562639276619) 117
 (7FC8F700D1C0) : 4 (CERROR "Try calling it again" "No applicable
method for args:~% ~s~% to ~s" [...]) 933
 (7FC8F700D258) : 5 (FUNCALL #'#<#<CCL::STANDARD-KERNEL-METHOD
NO-APPLICABLE-METHOD (T)>> #<STANDARD-GENERIC-FUNCTION
FLEXI-STREAMS::ENCODING-FACTOR #x300040FACA3F> [...]) 117
 (7FC8F700D298) : 7 (FUNCALL #'#<#<STANDARD-METHOD
TRIVIAL-GRAY-STREAMS:STREAM-WRITE-SEQUENCE
(FLEXI-STREAMS:FLEXI-OUTPUT-STREAM T T T)>>
#<FLEXI-STREAMS:FLEXI-IO-STREAM #x30004272511D> "....
 (7FC8F700D300) : 8 (%%STANDARD-COMBINED-METHOD-DCODE '(# NIL #<#>)
17562639276650) 269
 (7FC8F700D378) : 10 (WRITE-STRING "...
 (7FC8F700D3D8) : 11 (%PR-INTEGER 0 [...]) 965
 (7FC8F700D478) : 12 (FORMAT-PRINT-NUMBER
#<FLEXI-STREAMS:FLEXI-IO-STREAM #x30004272511D> 8187 16 NIL NIL NIL)
1829
 (7FC8F700D4F8) : 13 (FUNCALL #'#<Anonymous Function #x3000409324EF>
#<FLEXI-STREAMS:FLEXI-IO-STREAM #x30004272511D> NIL NIL [...]) 165
 (7FC8F700D530) : 14 (SUB-FORMAT #<FLEXI-STREAMS:FLEXI-IO-STREAM
#x30004272511D> 1 2) 2469
 (7FC8F700D5E8) : 15 (DO-SUB-FORMAT #<FLEXI-STREAMS:FLEXI-IO-STREAM
#x30004272511D>) 157
 (7FC8F700D608) : 16 (FORMAT #<FLEXI-STREAMS:FLEXI-IO-STREAM
#x30004272511D> "~X" [...]) 1725
 (7FC8F700D728) : 17 (FUNCALL #'#<#<STANDARD-METHOD
CHUNGA::WRITE-CHUNK (CHUNGA:CHUNKED-OUTPUT-STREAM T)>>
#<CHUNGA:CHUNKED-IO-STREAM #x30004273F56D> #(60 33 68 79 67 ...)
[...]) 237
 (7FC8F700D770) : 18 (%%CHECK-KEYWORDS #(2 #(:END :START)
#<METHOD-FUNCTION CHUNGA::WRITE-CHUNK #>) 17562639276793) 245
 (7FC8F700D7F0) : 20 (FUNCALL #'#<#<STANDARD-METHOD
CHUNGA::FLUSH-BUFFER (CHUNGA:CHUNKED-OUTPUT-STREAM)>>
#<CHUNGA:CHUNKED-IO-STREAM #x30004273F56D>) 213
 (7FC8F700D810) : 21 (FUNCALL #'#<#<STANDARD-METHOD
TRIVIAL-GRAY-STREAMS:STREAM-WRITE-SEQUENCE
(CHUNGA:CHUNKED-OUTPUT-STREAM T T T)>> #<CHUNGA:CHUNKED-IO-STREAM
#x30004273F56D> #(184 177 224 184 162 ...) 0 63 [...]) 709
 (7FC8F700D868) : 22 (WRITE-SEQUENCE #(184 177 224 184 162 ...)
#<CHUNGA:CHUNKED-IO-STREAM #x30004273F56D> [...]) 765
 (7FC8F700D8D8) : 23 (FUNCALL #'#<(:INTERNAL
FLEXI-STREAMS::FLUSH-BUFFER
(TRIVIAL-GRAY-STREAMS:STREAM-WRITE-SEQUENCE
(FLEXI-STREAMS:FLEXI-OUTPUT-STREAM T T T)))>) 85
 (7FC8F700D900) : 24 (FUNCALL #'#<(:INTERNAL
FLEXI-STREAMS::WRITE-OCTET (TRIVIAL-GRAY-STREAMS:STREAM-WRITE-SEQUENCE
(FLEXI-STREAMS:FLEXI-OUTPUT-STREAM T T T)))> 154) 69
 (7FC8F700D938) : 25 (FUNCALL #'#<#<STANDARD-METHOD
FLEXI-STREAMS::CHAR-TO-OCTETS (FLEXI-STREAMS::FLEXI-UTF-8-FORMAT T
T)>> #<FLEXI-UTF-8-FORMAT (:UTF-8 :EOL-STYLE :LF) #x300042642DBD>
#\U+0E1A #<COMPILED-LEXICAL-CLOSURE (:INTERNAL
FLEXI-STREAMS::WRITE-OCTET #) #x30004274A8CF>) 1629
 (7FC8F700D970) : 26 (FUNCALL #'#<#<STANDARD-METHOD
TRIVIAL-GRAY-STREAMS:STREAM-WRITE-SEQUENCE
(FLEXI-STREAMS:FLEXI-OUTPUT-STREAM T T T)>>
#<FLEXI-STREAMS:FLEXI-IO-STREAM #x30004273CBCD> "
 (7FC8F700D9F8) : 27 (%%STANDARD-COMBINED-METHOD-DCODE '(# NIL #<#>)
17562639276873) 269
 (7FC8F700DA70) : 29 (WRITE-STRING "...
 (7FC8F700DAD0) : 30 (WRITE-LINE "
 (7FC8F700DB20) : 31 (STREAM-DIRECT-UTF-8) 805
 (7FC8F700DBB0) : 32 (PROCESS-REQUEST '(# # # # # ...)
#<FLEXI-STREAMS:FLEXI-IO-STREAM #x30004273CBCD> :GET
"/hunchentoot/test/utf8-character.txt" :HTTP/1.1) 3045
 (7FC8F700DD18) : 33 (PROCESS-CONNECTION #<HUNCHENTOOT::SERVER
#x3000426BF81D> #<BASIC-TCP-STREAM ISO-8859-1 (SOCKET/6)
#x30004271F65D>) 5429
 (7FC8F700DEB8) : 34 (RUN-PROCESS-INITIAL-FORM #<PROCESS
hunchentoot-worker-1(13) [Active] #x30004271E9BD> '(#)) 717
 (7FC8F700DF48) : 35 (FUNCALL #'#<(:INTERNAL
CCL::%PROCESS-PRESET-INTERNAL)> #<PROCESS hunchentoot-worker-1(13)
[Active] #x30004271E9BD> '(#)) 397
 (7FC8F700DF98) : 36 (FUNCALL #'#<(:INTERNAL
CCL::THREAD-MAKE-STARTUP-FUNCTION)>) 293

CHUNGA INFO--->>>>>>>>>

Class: #<STANDARD-CLASS FLEXI-STREAMS:FLEXI-IO-STREAM>
Wrapper: #<CLASS-WRAPPER  #x300040FCCC3D>
Instance slots
CCL::SHARED-RESOURCE: NIL
STREAM: #<BASIC-TCP-STREAM ISO-8859-1 (SOCKET/6) #x3000426A322D>
FLEXI-STREAMS::EXTERNAL-FORMAT: #<EXTERNAL-FORMAT (:ISO-8859-1
                                                   :EOL-STYLE
                                                   :LF) #x30004122DA1D>
FLEXI-STREAMS::ELEMENT-TYPE: FLEXI-STREAMS::CHAR*
FLEXI-STREAMS::COLUMN: 0
FLEXI-STREAMS::LAST-CHAR-CODE: NIL
FLEXI-STREAMS::LAST-OCTET: NIL
FLEXI-STREAMS::OCTET-STACK: NIL
POSITION: 0
FLEXI-STREAMS::BOUND: NIL
#<FLEXI-STREAMS:FLEXI-IO-STREAM #x3000426A36BD>
Class: #<STANDARD-CLASS FLEXI-STREAMS:FLEXI-IO-STREAM>
Wrapper: #<CLASS-WRAPPER  #x300040FCCC3D>
Instance slots
CCL::SHARED-RESOURCE: NIL
STREAM: #<BASIC-TCP-STREAM ISO-8859-1 (SOCKET/6) #x3000426A322D>
FLEXI-STREAMS::EXTERNAL-FORMAT: #<EXTERNAL-FORMAT (:ISO-8859-1
                                                   :EOL-STYLE
                                                   :LF) #x30004122DA1D>
FLEXI-STREAMS::ELEMENT-TYPE: FLEXI-STREAMS::CHAR*
FLEXI-STREAMS::COLUMN: 0
FLEXI-STREAMS::LAST-CHAR-CODE: NIL
FLEXI-STREAMS::LAST-OCTET: NIL
FLEXI-STREAMS::OCTET-STACK: NIL
POSITION: 0
FLEXI-STREAMS::BOUND: NIL


From wade.humeniuk at gmail.com  Mon Jun 16 05:10:09 2008
From: wade.humeniuk at gmail.com (Wade Humeniuk)
Date: Sun, 15 Jun 2008 23:10:09 -0600
Subject: [hunchentoot-devel] Re: Clozure CL HUNCHENTOOT-TEST Error
In-Reply-To: <4a8bfaea0806152152i4abaf4a1l8566f136f25cac07@mail.gmail.com>
References: <4a8bfaea0806152152i4abaf4a1l8566f136f25cac07@mail.gmail.com>
Message-ID: <4a8bfaea0806152210lbff3a8dr341f63692f4dd8d9@mail.gmail.com>

As with many things, just writing the problem down has lead to a solution.
I have rebuilt my ccl recently from the latest subversion development.
I thought all this functionality was working before, so I just cleared out
all the compiled files in my asdf-install-dir and rebuilt hunchentoot,
flexi-streams, chunga ...  and the problem went away.

Wade

On Sun, Jun 15, 2008 at 10:52 PM, Wade Humeniuk <wade.humeniuk at gmail.com> wrote:
> I am using Clozure CL 1.2 rc1.2 with Hunchentoot.  The
> hunchentoot-test pages that come with the install
> are not working completely.  I had the to modify the test code in
> test.lisp to get a backtrace of what was
> happening.  stream-direct-utf-8 is throwing an error and no content is
> coming back.
>
> (defvar *htest-debug-stream* nil)
>
> (defun stream-direct-utf-8 ()
>  (handler-bind ((error (lambda (c)
>                          (describe c *htest-debug-stream*)
>                          (format *htest-debug-stream* "~A" (hunchentoot:get-backtrace c)))))
>    (setf (content-type) "text/html; charset=utf-8")
>    (let ((stream (send-headers)))
>      (setf (flex:flexi-stream-external-format stream) *utf-8*)
>      (with-open-file (in (merge-pathnames "UTF-8-demo.html" *this-file*)
>                          :element-type 'flex:octet)
>        (setq in (flex:make-flexi-stream in :external-format *utf-8*))
>        (loop for line = (read-line in nil nil)
>           while line
>           do (write-line line stream))))))
>
> and modifying chunga::write-chunk to..
>
> (defmethod write-chunk ((stream chunked-output-stream) sequence
>                        &key (start 0)
>                             (end (length sequence)))
>  "Writes the contents of SEQUENCE from START to END to the
> underlying stream of STREAM as one chunk."
>  (let ((output-stream (chunked-stream-output-stream stream)))
>    (describe output-stream hunchentoot-test::*htest-debug-stream*)
>    ;; chunk size
>    (format output-stream "~X" (- end start))
>    ;; CRLF
>    (write-string #.(format nil "~C~C" #\Return #\Linefeed) output-stream)
>    ;; data
>    #+:clisp (setf (flexi-stream-element-type output-stream) 'octet)
>    (write-sequence sequence output-stream :start start :end end)
>    #+:clisp (setf (flexi-stream-element-type output-stream) 'character)
>    ;; CRLF
>    (write-string #.(format nil "~C~C" #\Return #\Linefeed) output-stream)))
>
>
>
> Visting the page /hunchentoot/test/utf8-character.txt produces the output below.
> As far as I can tell from looking at the code there should be no instance of
> EXTERNAL-FORMAT since there is no method FLEXI-STREAMS::ENCODING-FACTOR
> for it  (only subclasses of EXTERNAL-FORMAT).  I have pretty well banged my head
> looking at the code in flexi-streams and chunga trying to determine the problem.
> This works fine for SBCL, and I see no conditional code for CCL that
> might explain the
> problem.
>
> Wade
>
> CL-USER> (hunchentoot:start-server :port 4242)
> #<HUNCHENTOOT::SERVER #x3000426BF81D>
> CL-USER> (setf hunchentoot-test::*htest-debug-stream* *standard-output*)
> #<SWANK-BACKEND::SLIME-OUTPUT-STREAM #x300040E2FC1D>
> #<SIMPLE-ERROR #x30004274A50D>
> Class: #<STANDARD-CLASS SIMPLE-ERROR>
> Wrapper: #<CLASS-WRAPPER  #x3000404AC86D>
> Instance slots
> CCL::FORMAT-CONTROL: "No applicable method for args:~% ~s~% to ~s"
> CCL::FORMAT-ARGUMENTS: ((#<EXTERNAL-FORMAT (:ISO-8859-1
>                                            :EOL-STYLE
>                                            :LF) #x30004122DA1D>)
>                        #<STANDARD-GENERIC-FUNCTION
> FLEXI-STREAMS::ENCODING-FACTOR #x300040FACA3F>)
>
>
> BACKTRACE--->>>>>>
>
>  (7FC8F700D0B8) : 0 (GET-BACKTRACE #<SIMPLE-ERROR #x30004274A50D>) 285
>  (7FC8F700D120) : 1 (FUNCALL #'#<(:INTERNAL
> HUNCHENTOOT-TEST::STREAM-DIRECT-UTF-8)> #<SIMPLE-ERROR
> #x30004274A50D>) 173
>  (7FC8F700D140) : 2 (SIGNAL #<SIMPLE-ERROR #x30004274A50D> [...]) 997
>  (7FC8F700D198) : 3 (%ERROR #<SIMPLE-ERROR #x30004274A50D> NIL
> 17562639276619) 117
>  (7FC8F700D1C0) : 4 (CERROR "Try calling it again" "No applicable
> method for args:~% ~s~% to ~s" [...]) 933
>  (7FC8F700D258) : 5 (FUNCALL #'#<#<CCL::STANDARD-KERNEL-METHOD
> NO-APPLICABLE-METHOD (T)>> #<STANDARD-GENERIC-FUNCTION
> FLEXI-STREAMS::ENCODING-FACTOR #x300040FACA3F> [...]) 117
>  (7FC8F700D298) : 7 (FUNCALL #'#<#<STANDARD-METHOD
> TRIVIAL-GRAY-STREAMS:STREAM-WRITE-SEQUENCE
> (FLEXI-STREAMS:FLEXI-OUTPUT-STREAM T T T)>>
> #<FLEXI-STREAMS:FLEXI-IO-STREAM #x30004272511D> "....
>  (7FC8F700D300) : 8 (%%STANDARD-COMBINED-METHOD-DCODE '(# NIL #<#>)
> 17562639276650) 269
>  (7FC8F700D378) : 10 (WRITE-STRING "...
>  (7FC8F700D3D8) : 11 (%PR-INTEGER 0 [...]) 965
>  (7FC8F700D478) : 12 (FORMAT-PRINT-NUMBER
> #<FLEXI-STREAMS:FLEXI-IO-STREAM #x30004272511D> 8187 16 NIL NIL NIL)
> 1829
>  (7FC8F700D4F8) : 13 (FUNCALL #'#<Anonymous Function #x3000409324EF>
> #<FLEXI-STREAMS:FLEXI-IO-STREAM #x30004272511D> NIL NIL [...]) 165
>  (7FC8F700D530) : 14 (SUB-FORMAT #<FLEXI-STREAMS:FLEXI-IO-STREAM
> #x30004272511D> 1 2) 2469
>  (7FC8F700D5E8) : 15 (DO-SUB-FORMAT #<FLEXI-STREAMS:FLEXI-IO-STREAM
> #x30004272511D>) 157
>  (7FC8F700D608) : 16 (FORMAT #<FLEXI-STREAMS:FLEXI-IO-STREAM
> #x30004272511D> "~X" [...]) 1725
>  (7FC8F700D728) : 17 (FUNCALL #'#<#<STANDARD-METHOD
> CHUNGA::WRITE-CHUNK (CHUNGA:CHUNKED-OUTPUT-STREAM T)>>
> #<CHUNGA:CHUNKED-IO-STREAM #x30004273F56D> #(60 33 68 79 67 ...)
> [...]) 237
>  (7FC8F700D770) : 18 (%%CHECK-KEYWORDS #(2 #(:END :START)
> #<METHOD-FUNCTION CHUNGA::WRITE-CHUNK #>) 17562639276793) 245
>  (7FC8F700D7F0) : 20 (FUNCALL #'#<#<STANDARD-METHOD
> CHUNGA::FLUSH-BUFFER (CHUNGA:CHUNKED-OUTPUT-STREAM)>>
> #<CHUNGA:CHUNKED-IO-STREAM #x30004273F56D>) 213
>  (7FC8F700D810) : 21 (FUNCALL #'#<#<STANDARD-METHOD
> TRIVIAL-GRAY-STREAMS:STREAM-WRITE-SEQUENCE
> (CHUNGA:CHUNKED-OUTPUT-STREAM T T T)>> #<CHUNGA:CHUNKED-IO-STREAM
> #x30004273F56D> #(184 177 224 184 162 ...) 0 63 [...]) 709
>  (7FC8F700D868) : 22 (WRITE-SEQUENCE #(184 177 224 184 162 ...)
> #<CHUNGA:CHUNKED-IO-STREAM #x30004273F56D> [...]) 765
>  (7FC8F700D8D8) : 23 (FUNCALL #'#<(:INTERNAL
> FLEXI-STREAMS::FLUSH-BUFFER
> (TRIVIAL-GRAY-STREAMS:STREAM-WRITE-SEQUENCE
> (FLEXI-STREAMS:FLEXI-OUTPUT-STREAM T T T)))>) 85
>  (7FC8F700D900) : 24 (FUNCALL #'#<(:INTERNAL
> FLEXI-STREAMS::WRITE-OCTET (TRIVIAL-GRAY-STREAMS:STREAM-WRITE-SEQUENCE
> (FLEXI-STREAMS:FLEXI-OUTPUT-STREAM T T T)))> 154) 69
>  (7FC8F700D938) : 25 (FUNCALL #'#<#<STANDARD-METHOD
> FLEXI-STREAMS::CHAR-TO-OCTETS (FLEXI-STREAMS::FLEXI-UTF-8-FORMAT T
> T)>> #<FLEXI-UTF-8-FORMAT (:UTF-8 :EOL-STYLE :LF) #x300042642DBD>
> #\U+0E1A #<COMPILED-LEXICAL-CLOSURE (:INTERNAL
> FLEXI-STREAMS::WRITE-OCTET #) #x30004274A8CF>) 1629
>  (7FC8F700D970) : 26 (FUNCALL #'#<#<STANDARD-METHOD
> TRIVIAL-GRAY-STREAMS:STREAM-WRITE-SEQUENCE
> (FLEXI-STREAMS:FLEXI-OUTPUT-STREAM T T T)>>
> #<FLEXI-STREAMS:FLEXI-IO-STREAM #x30004273CBCD> "
>  (7FC8F700D9F8) : 27 (%%STANDARD-COMBINED-METHOD-DCODE '(# NIL #<#>)
> 17562639276873) 269
>  (7FC8F700DA70) : 29 (WRITE-STRING "...
>  (7FC8F700DAD0) : 30 (WRITE-LINE "
>  (7FC8F700DB20) : 31 (STREAM-DIRECT-UTF-8) 805
>  (7FC8F700DBB0) : 32 (PROCESS-REQUEST '(# # # # # ...)
> #<FLEXI-STREAMS:FLEXI-IO-STREAM #x30004273CBCD> :GET
> "/hunchentoot/test/utf8-character.txt" :HTTP/1.1) 3045
>  (7FC8F700DD18) : 33 (PROCESS-CONNECTION #<HUNCHENTOOT::SERVER
> #x3000426BF81D> #<BASIC-TCP-STREAM ISO-8859-1 (SOCKET/6)
> #x30004271F65D>) 5429
>  (7FC8F700DEB8) : 34 (RUN-PROCESS-INITIAL-FORM #<PROCESS
> hunchentoot-worker-1(13) [Active] #x30004271E9BD> '(#)) 717
>  (7FC8F700DF48) : 35 (FUNCALL #'#<(:INTERNAL
> CCL::%PROCESS-PRESET-INTERNAL)> #<PROCESS hunchentoot-worker-1(13)
> [Active] #x30004271E9BD> '(#)) 397
>  (7FC8F700DF98) : 36 (FUNCALL #'#<(:INTERNAL
> CCL::THREAD-MAKE-STARTUP-FUNCTION)>) 293
>
> CHUNGA INFO--->>>>>>>>>
>
> Class: #<STANDARD-CLASS FLEXI-STREAMS:FLEXI-IO-STREAM>
> Wrapper: #<CLASS-WRAPPER  #x300040FCCC3D>
> Instance slots
> CCL::SHARED-RESOURCE: NIL
> STREAM: #<BASIC-TCP-STREAM ISO-8859-1 (SOCKET/6) #x3000426A322D>
> FLEXI-STREAMS::EXTERNAL-FORMAT: #<EXTERNAL-FORMAT (:ISO-8859-1
>                                                   :EOL-STYLE
>                                                   :LF) #x30004122DA1D>
> FLEXI-STREAMS::ELEMENT-TYPE: FLEXI-STREAMS::CHAR*
> FLEXI-STREAMS::COLUMN: 0
> FLEXI-STREAMS::LAST-CHAR-CODE: NIL
> FLEXI-STREAMS::LAST-OCTET: NIL
> FLEXI-STREAMS::OCTET-STACK: NIL
> POSITION: 0
> FLEXI-STREAMS::BOUND: NIL
> #<FLEXI-STREAMS:FLEXI-IO-STREAM #x3000426A36BD>
> Class: #<STANDARD-CLASS FLEXI-STREAMS:FLEXI-IO-STREAM>
> Wrapper: #<CLASS-WRAPPER  #x300040FCCC3D>
> Instance slots
> CCL::SHARED-RESOURCE: NIL
> STREAM: #<BASIC-TCP-STREAM ISO-8859-1 (SOCKET/6) #x3000426A322D>
> FLEXI-STREAMS::EXTERNAL-FORMAT: #<EXTERNAL-FORMAT (:ISO-8859-1
>                                                   :EOL-STYLE
>                                                   :LF) #x30004122DA1D>
> FLEXI-STREAMS::ELEMENT-TYPE: FLEXI-STREAMS::CHAR*
> FLEXI-STREAMS::COLUMN: 0
> FLEXI-STREAMS::LAST-CHAR-CODE: NIL
> FLEXI-STREAMS::LAST-OCTET: NIL
> FLEXI-STREAMS::OCTET-STACK: NIL
> POSITION: 0
> FLEXI-STREAMS::BOUND: NIL
>


From lispercat at gmail.com  Fri Jun 20 16:56:33 2008
From: lispercat at gmail.com (Andrei Stebakov)
Date: Fri, 20 Jun 2008 12:56:33 -0400
Subject: [hunchentoot-devel] Static file handling performance
Message-ID: <affe56e00806200956g6fe3b351ua63e4237f8df4782@mail.gmail.com>

I had to come up with some way to cache dynamic files that I have to serve,
so I ended up with a bunch of static files which I served by a simple
function:
(defun file-to-string (path)
  "Reads a file into a string"
  (if (probe-file path)
      (with-open-file (in path)
        (let ((str (make-string (file-length in))))
          (read-sequence str in)
          str))))

The performance was very good, but then I thought that it's not the proper
way to serve static files as there is a hunchentoot function
handle-static-file.
When I started using the hunchentoot's function the response time almost
tripled and when I run "top" program to monitor CPU usage it jumps up to 60%
(on my PIII 600 MHz) CPU,
whereas using file-to-string CPU usage stays with 2% (maybe because the
serving time is much shorter top doesn't catch that CPU peak).
My question is what could be the reason I see this behaviour? (I am using
SBCL 1.0.15 with latest dependences of hunchentoot-0.15.7)

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

From lispercat at gmail.com  Fri Jun 20 17:29:00 2008
From: lispercat at gmail.com (Andrei Stebakov)
Date: Fri, 20 Jun 2008 13:29:00 -0400
Subject: [hunchentoot-devel] Re: Static file handling performance
In-Reply-To: <affe56e00806200956g6fe3b351ua63e4237f8df4782@mail.gmail.com>
References: <affe56e00806200956g6fe3b351ua63e4237f8df4782@mail.gmail.com>
Message-ID: <affe56e00806201029l37d411a4r34cc9f6791f6cfa4@mail.gmail.com>

I forgot to mention that this is only for text static files like html.

On Fri, Jun 20, 2008 at 12:56 PM, Andrei Stebakov <lispercat at gmail.com>
wrote:

> I had to come up with some way to cache dynamic files that I have to serve,
> so I ended up with a bunch of static files which I served by a simple
> function:
> (defun file-to-string (path)
>   "Reads a file into a string"
>   (if (probe-file path)
>       (with-open-file (in path)
>         (let ((str (make-string (file-length in))))
>           (read-sequence str in)
>           str))))
>
> The performance was very good, but then I thought that it's not the proper
> way to serve static files as there is a hunchentoot function
> handle-static-file.
> When I started using the hunchentoot's function the response time almost
> tripled and when I run "top" program to monitor CPU usage it jumps up to 60%
> (on my PIII 600 MHz) CPU,
> whereas using file-to-string CPU usage stays with 2% (maybe because the
> serving time is much shorter top doesn't catch that CPU peak).
> My question is what could be the reason I see this behaviour? (I am using
> SBCL 1.0.15 with latest dependences of hunchentoot-0.15.7)
>
> Thank you,
> Andrew
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20080620/5e14a522/attachment.html>

From edi at agharta.de  Fri Jun 20 18:20:48 2008
From: edi at agharta.de (Edi Weitz)
Date: Fri, 20 Jun 2008 20:20:48 +0200
Subject: [hunchentoot-devel] Static file handling performance
In-Reply-To: <affe56e00806200956g6fe3b351ua63e4237f8df4782@mail.gmail.com>
	(Andrei Stebakov's message of "Fri, 20 Jun 2008 12:56:33 -0400")
References: <affe56e00806200956g6fe3b351ua63e4237f8df4782@mail.gmail.com>
Message-ID: <ulk10hssf.fsf@agharta.de>

On Fri, 20 Jun 2008 12:56:33 -0400, "Andrei Stebakov" <lispercat at gmail.com> wrote:

> I had to come up with some way to cache dynamic files that I have to
> serve, so I ended up with a bunch of static files which I served by
> a simple function:
> (defun file-to-string (path)
>   "Reads a file into a string"
>   (if (probe-file path)
>       (with-open-file (in path)
>         (let ((str (make-string (file-length in))))
>           (read-sequence str in)
>           str))))
>
> The performance was very good, but then I thought that it's not the
> proper way to serve static files as there is a hunchentoot function
> handle-static-file.
> When I started using the hunchentoot's function the response time
> almost tripled and when I run "top" program to monitor CPU usage it
> jumps up to 60% (on my PIII 600 MHz) CPU, whereas using
> file-to-string CPU usage stays with 2% (maybe because the serving
> time is much shorter top doesn't catch that CPU peak).

How did you measure the response time?  Which version of FLEXI-STREAMS
are you using?  Did you try with the development version?

> My question is what could be the reason I see this behaviour? (I am
> using SBCL 1.0.15 with latest dependences of hunchentoot-0.15.7)

Look at the source code of handle-static-file.  It uses a fixed size
buffer which is likely smaller than your file.


From lispercat at gmail.com  Fri Jun 20 18:41:07 2008
From: lispercat at gmail.com (Andrei Stebakov)
Date: Fri, 20 Jun 2008 14:41:07 -0400
Subject: [hunchentoot-devel] Static file handling performance
In-Reply-To: <ulk10hssf.fsf@agharta.de>
References: <affe56e00806200956g6fe3b351ua63e4237f8df4782@mail.gmail.com>
	<ulk10hssf.fsf@agharta.de>
Message-ID: <affe56e00806201141g3c7e734cm57dfedf9c1047f07@mail.gmail.com>

I use flexi-streams-0.15.3.
I didn't measure the response time using any tools (like httperf), I was
just visually evaluating response time. It was much longer for
handle-static-file. No, I didn't try the development version yet, I'll try
it.


On Fri, Jun 20, 2008 at 2:20 PM, Edi Weitz <edi at agharta.de> wrote:

> On Fri, 20 Jun 2008 12:56:33 -0400, "Andrei Stebakov" <lispercat at gmail.com>
> wrote:
>
> > I had to come up with some way to cache dynamic files that I have to
> > serve, so I ended up with a bunch of static files which I served by
> > a simple function:
> > (defun file-to-string (path)
> >   "Reads a file into a string"
> >   (if (probe-file path)
> >       (with-open-file (in path)
> >         (let ((str (make-string (file-length in))))
> >           (read-sequence str in)
> >           str))))
> >
> > The performance was very good, but then I thought that it's not the
> > proper way to serve static files as there is a hunchentoot function
> > handle-static-file.
> > When I started using the hunchentoot's function the response time
> > almost tripled and when I run "top" program to monitor CPU usage it
> > jumps up to 60% (on my PIII 600 MHz) CPU, whereas using
> > file-to-string CPU usage stays with 2% (maybe because the serving
> > time is much shorter top doesn't catch that CPU peak).
>
> How did you measure the response time?  Which version of FLEXI-STREAMS
> are you using?  Did you try with the development version?
>
> > My question is what could be the reason I see this behaviour? (I am
> > using SBCL 1.0.15 with latest dependences of hunchentoot-0.15.7)
>
> Look at the source code of handle-static-file.  It uses a fixed size
> buffer which is likely smaller than your file.
> _______________________________________________
> 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/20080620/3e864d0c/attachment.html>

From lispercat at gmail.com  Fri Jun 20 20:18:16 2008
From: lispercat at gmail.com (Andrei Stebakov)
Date: Fri, 20 Jun 2008 16:18:16 -0400
Subject: [hunchentoot-devel] Static file handling performance
In-Reply-To: <ulk10hssf.fsf@agharta.de>
References: <affe56e00806200956g6fe3b351ua63e4237f8df4782@mail.gmail.com>
	<ulk10hssf.fsf@agharta.de>
Message-ID: <affe56e00806201318o2e33a7dfj16ed6a7325d18271@mail.gmail.com>

I did some tests with httperf:

*First test with file-to-string function:*

Total: connections 100 requests 100 replies 89 test-duration 67.869 s

Connection rate: 1.5 conn/s (678.7 ms/conn, <=1 concurrent connections)
Connection time [ms]: min 492.0 avg 638.7 max 1151.0 median 572.5 stddev
150.4
Connection time [ms]: connect 1.3
Connection length [replies/conn]: 1.000

Request rate: 1.5 req/s (678.7 ms/req)
Request size [B]: 93.0

Reply rate [replies/s]: min 1.0 avg 1.3 max 1.8 stddev 0.2 (13 samples)
Reply time [ms]: response 511.0 transfer 126.4
Reply size [B]: header 368.0 content 21324.0 footer 0.0 (total 21692.0)
Reply status: 1xx=0 2xx=89 3xx=0 4xx=0 5xx=0

CPU time [s]: user 28.77 system 38.89 (user 42.4% system 57.3% total 99.7%)
Net I/O: 27.9 KB/s (0.2*10^6 bps)

Errors: total 11 client-timo 11 socket-timo 0 connrefused 0 connreset 0
Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0



*Second test with handle-static-file:*

Total: connections 100 requests 100 replies 16 test-duration 93.867 s

Connection rate: 1.1 conn/s (938.7 ms/conn, <=1 concurrent connections)
Connection time [ms]: min 594.0 avg 807.4 max 1393.0 median 690.5 stddev
240.2
Connection time [ms]: connect 0.6
Connection length [replies/conn]: 1.000

Request rate: 1.1 req/s (938.7 ms/req)
Request size [B]: 93.0

Reply rate [replies/s]: min 0.0 avg 0.2 max 1.0 stddev 0.3 (18 samples)
Reply time [ms]: response 637.1 transfer 166.0
Reply size [B]: header 348.0 content 21324.0 footer 0.0 (total 21672.0)
Reply status: 1xx=0 2xx=16 3xx=0 4xx=0 5xx=0

CPU time [s]: user 40.12 system 53.39 (user 42.7% system 56.9% total 99.6%)
Net I/O: 3.7 KB/s (0.0*10^6 bps)

Errors: total 84 client-timo 79 socket-timo 0 connrefused 0 connreset 5
Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0

As can be seen from the second test there were lots of time-out requests.
Also as I was watching the CPU usage (with top) during first test CPU load
was ~2%, during second test the CPU load was ~90% with memory constantly
growing and shrinking (probably GC was causing this load). Also during some
of handle-static-file tests I ran into heap allocation problems so I had to
unload the lisp image and restart it.
Well, it could be just my particular system's problem.

Andrew

On Fri, Jun 20, 2008 at 2:20 PM, Edi Weitz <edi at agharta.de> wrote:

> On Fri, 20 Jun 2008 12:56:33 -0400, "Andrei Stebakov" <lispercat at gmail.com>
> wrote:
>
> > I had to come up with some way to cache dynamic files that I have to
> > serve, so I ended up with a bunch of static files which I served by
> > a simple function:
> > (defun file-to-string (path)
> >   "Reads a file into a string"
> >   (if (probe-file path)
> >       (with-open-file (in path)
> >         (let ((str (make-string (file-length in))))
> >           (read-sequence str in)
> >           str))))
> >
> > The performance was very good, but then I thought that it's not the
> > proper way to serve static files as there is a hunchentoot function
> > handle-static-file.
> > When I started using the hunchentoot's function the response time
> > almost tripled and when I run "top" program to monitor CPU usage it
> > jumps up to 60% (on my PIII 600 MHz) CPU, whereas using
> > file-to-string CPU usage stays with 2% (maybe because the serving
> > time is much shorter top doesn't catch that CPU peak).
>
> How did you measure the response time?  Which version of FLEXI-STREAMS
> are you using?  Did you try with the development version?
>
> > My question is what could be the reason I see this behaviour? (I am
> > using SBCL 1.0.15 with latest dependences of hunchentoot-0.15.7)
>
> Look at the source code of handle-static-file.  It uses a fixed size
> buffer which is likely smaller than your file.
> _______________________________________________
> 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/20080620/33aa8de3/attachment.html>

From edi at agharta.de  Fri Jun 20 20:44:44 2008
From: edi at agharta.de (Edi Weitz)
Date: Fri, 20 Jun 2008 22:44:44 +0200
Subject: [hunchentoot-devel] Static file handling performance
In-Reply-To: <affe56e00806201141g3c7e734cm57dfedf9c1047f07@mail.gmail.com>
	(Andrei Stebakov's message of "Fri, 20 Jun 2008 14:41:07 -0400")
References: <affe56e00806200956g6fe3b351ua63e4237f8df4782@mail.gmail.com>
	<ulk10hssf.fsf@agharta.de>
	<affe56e00806201141g3c7e734cm57dfedf9c1047f07@mail.gmail.com>
Message-ID: <uabhfj0oz.fsf@agharta.de>

On Fri, 20 Jun 2008 14:41:07 -0400, "Andrei Stebakov" <lispercat at gmail.com> wrote:

> I use flexi-streams-0.15.3.

Use flexi-streams 1.x.x if you're interested in performance.


From lispercat at gmail.com  Fri Jun 20 21:01:06 2008
From: lispercat at gmail.com (Andrei Stebakov)
Date: Fri, 20 Jun 2008 17:01:06 -0400
Subject: [hunchentoot-devel] Static file handling performance
In-Reply-To: <uabhfj0oz.fsf@agharta.de>
References: <affe56e00806200956g6fe3b351ua63e4237f8df4782@mail.gmail.com>
	<ulk10hssf.fsf@agharta.de>
	<affe56e00806201141g3c7e734cm57dfedf9c1047f07@mail.gmail.com>
	<uabhfj0oz.fsf@agharta.de>
Message-ID: <affe56e00806201401ne2e9a9fu245533ea78f6528f@mail.gmail.com>

Updated to flexi-streams-1.0.3. Same results. With handle-static-file there
are lots of heap exhaustion errors and CPU load goes up to 99%.



On Fri, Jun 20, 2008 at 4:44 PM, Edi Weitz <edi at agharta.de> wrote:

> On Fri, 20 Jun 2008 14:41:07 -0400, "Andrei Stebakov" <lispercat at gmail.com>
> wrote:
>
> > I use flexi-streams-0.15.3.
>
> Use flexi-streams 1.x.x if you're interested in performance.
> _______________________________________________
> 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/20080620/80b40c9d/attachment.html>

From edi at agharta.de  Fri Jun 20 22:03:42 2008
From: edi at agharta.de (Edi Weitz)
Date: Sat, 21 Jun 2008 00:03:42 +0200
Subject: [hunchentoot-devel] Static file handling performance
In-Reply-To: <affe56e00806201401ne2e9a9fu245533ea78f6528f@mail.gmail.com>
	(Andrei Stebakov's message of "Fri, 20 Jun 2008 17:01:06 -0400")
References: <affe56e00806200956g6fe3b351ua63e4237f8df4782@mail.gmail.com>
	<ulk10hssf.fsf@agharta.de>
	<affe56e00806201141g3c7e734cm57dfedf9c1047f07@mail.gmail.com>
	<uabhfj0oz.fsf@agharta.de>
	<affe56e00806201401ne2e9a9fu245533ea78f6528f@mail.gmail.com>
Message-ID: <u63s3ix1d.fsf@agharta.de>

On Fri, 20 Jun 2008 17:01:06 -0400, "Andrei Stebakov" <lispercat at gmail.com> wrote:

> With handle-static-file there are lots of heap exhaustion errors and
> CPU load goes up to 99%.

No explanation for that.  How big is your file?  Have you tried with
another file, maybe on another partition?  Can you try on another
machine?


From lispercat at gmail.com  Fri Jun 20 22:05:34 2008
From: lispercat at gmail.com (Andrei Stebakov)
Date: Fri, 20 Jun 2008 18:05:34 -0400
Subject: [hunchentoot-devel] Static file handling performance
In-Reply-To: <u63s3ix1d.fsf@agharta.de>
References: <affe56e00806200956g6fe3b351ua63e4237f8df4782@mail.gmail.com>
	<ulk10hssf.fsf@agharta.de>
	<affe56e00806201141g3c7e734cm57dfedf9c1047f07@mail.gmail.com>
	<uabhfj0oz.fsf@agharta.de>
	<affe56e00806201401ne2e9a9fu245533ea78f6528f@mail.gmail.com>
	<u63s3ix1d.fsf@agharta.de>
Message-ID: <affe56e00806201505h4cc2bcbk7d39e5beea9a5b66@mail.gmail.com>

Yes, I'll try different combinations that I can come up with. I understand
there is no logical explanation for this so far...

On Fri, Jun 20, 2008 at 6:03 PM, Edi Weitz <edi at agharta.de> wrote:

> On Fri, 20 Jun 2008 17:01:06 -0400, "Andrei Stebakov" <lispercat at gmail.com>
> wrote:
>
> > With handle-static-file there are lots of heap exhaustion errors and
> > CPU load goes up to 99%.
>
> No explanation for that.  How big is your file?  Have you tried with
> another file, maybe on another partition?  Can you try on another
> machine?
> _______________________________________________
> 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/20080620/05b7927c/attachment.html>

From ch-tbnl at bobobeach.com  Mon Jun 23 22:50:27 2008
From: ch-tbnl at bobobeach.com (Cyrus Harmon)
Date: Mon, 23 Jun 2008 15:50:27 -0700
Subject: [hunchentoot-devel] cl-webdav errors
Message-ID: <73D0B298-A665-4800-8E6C-1E6AF31C906D@bobobeach.com>

I'm getting some errors attempting to build the latest cl-webdav with  
the latest ediware/sbcl combo.

1) flex:flexi-stream-encoding-error is undefined. this is fixed by this:

diff --git a/util.lisp b/util.lisp
index 85b3afd..4f85165 100755
--- a/util.lisp
+++ b/util.lisp
@@ -90,5 +90,5 @@ then uses LATIN-1 if that fails."
    ;; LATIN-1...
    (handler-case
        (url-decode string +utf-8+)
-    (flex:flexi-stream-encoding-error ()
+    (flex:external-format-encoding-error ()
        (url-decode string +latin-1+))))

2) perhaps the recent constant dumping stuff in SBCL is giving cl- 
webdav fits here, but I get the following error message:

; compiling file "/Users/sly/src/lisp/cl-webdav/cl-webdav-0.1.2-git/ 
properties.lisp" (written 17 APR 2007 12:42:08 AM):
; compiling (IN-PACKAGE :CL-WEBDAV)
; compiling (DEFUN PROPERTY-EQUAL ...)
; compiling (DEFUN DAV-PROPERTY-FUNCTION ...)

; file: /Users/sly/src/lisp/cl-webdav/cl-webdav-0.1.2-git/ 
properties.lisp
; in: DEFUN DAV-PROPERTY-FUNCTION
;     (ASSOC CL-WEBDAV::PROPERTY CL-WEBDAV::+DAV-PROPERTY-ALIST+ :TEST  
#'STRING=)
; --> LET IF IF IF IF IF IF IF IF IF IF LET
; ==>
;   '("lockdiscovery" . #<CLOSURE # {13A90B0D}>)
;
; caught ERROR:
;   Objects of type FUNCTION can't be dumped into fasl files.

; --> LET IF IF IF IF IF IF IF IF IF IF
; ==>
;   '("lockdiscovery" . #<CLOSURE # {13A90B0D}>)
;
; caught ERROR:
;   Objects of type FUNCTION can't be dumped into fasl files.

; --> LET IF IF IF IF IF IF IF IF IF IF IF LET
; ==>
;   '("supportedlock" . #<CLOSURE # {13A90B1D}>)
;
; caught ERROR:
;   Objects of type FUNCTION can't be dumped into fasl files.

; --> LET IF IF IF IF IF IF IF IF IF IF IF
; ==>
;   '("supportedlock" . #<CLOSURE # {13A90B1D}>)
;
; caught ERROR:
;   Objects of type FUNCTION can't be dumped into fasl files.

; compiling (DEFUN GET-DEAD-PROPERTY ...)


are we attempting to do something out of the CL spec here or is SBCL  
choking on legal code?

thanks,

Cyrus





From edi at agharta.de  Mon Jun 23 23:16:37 2008
From: edi at agharta.de (Edi Weitz)
Date: Tue, 24 Jun 2008 01:16:37 +0200
Subject: [hunchentoot-devel] cl-webdav errors
In-Reply-To: <73D0B298-A665-4800-8E6C-1E6AF31C906D@bobobeach.com> (Cyrus
	Harmon's message of "Mon, 23 Jun 2008 15:50:27 -0700")
References: <73D0B298-A665-4800-8E6C-1E6AF31C906D@bobobeach.com>
Message-ID: <uod5rn3my.fsf@agharta.de>

On Mon, 23 Jun 2008 15:50:27 -0700, Cyrus Harmon <ch-tbnl at bobobeach.com> wrote:

> I'm getting some errors attempting to build the latest cl-webdav
> with the latest ediware/sbcl combo.

Yes, that's to be expected.  I haven't looked at cl-webdav in the last
months.

> are we attempting to do something out of the CL spec here or is SBCL
> choking on legal code?

I think SBCL is right.  (CONSTANTLY NIL) should be replaced by the
name of a function which does the same.


From ch-tbnl at bobobeach.com  Mon Jun 23 23:36:10 2008
From: ch-tbnl at bobobeach.com (Cyrus Harmon)
Date: Mon, 23 Jun 2008 16:36:10 -0700
Subject: [hunchentoot-devel] cl-webdav errors
In-Reply-To: <uod5rn3my.fsf@agharta.de>
References: <73D0B298-A665-4800-8E6C-1E6AF31C906D@bobobeach.com>
	<uod5rn3my.fsf@agharta.de>
Message-ID: <E353823A-DE61-4BBA-AC50-105DE43FE98A@bobobeach.com>


On Jun 23, 2008, at 4:16 PM, Edi Weitz wrote:

> On Mon, 23 Jun 2008 15:50:27 -0700, Cyrus Harmon <ch-tbnl at bobobeach.com 
> > wrote:
>
>> I'm getting some errors attempting to build the latest cl-webdav
>> with the latest ediware/sbcl combo.
>
> Yes, that's to be expected.  I haven't looked at cl-webdav in the last
> months.

Hmm... ok.

>> are we attempting to do something out of the CL spec here or is SBCL
>> choking on legal code?
>
> I think SBCL is right.  (CONSTANTLY NIL) should be replaced by the
> name of a function which does the same.

Alright, I'm taking a stab at getting this to work then. It sort  
builds now, but doesn't work.

In an effort to figure out why not, I've discovered that tbnl:*catch- 
errors-p* is still exported but doesn't exist anymore.


Here's my first cut at things:


diff --git a/handlers.lisp b/handlers.lisp
index 8f00ea6..2facb08 100755
--- a/handlers.lisp
+++ b/handlers.lisp
@@ -91,7 +91,7 @@ determined by *ALLOWED-METHODS* and *DAV-COMPLIANCE- 
CLASSES*."
  content body \(if there is one) and returns a corresponding
  \"multistatus\" XML element using the methods for live and dead
  properties."
-  (let* ((depth-header (header-in :depth))
+  (let* ((depth-header (header-in* :depth))
           (depth-value (cond ((or (null depth-header)
                                   (string-equal depth-header  
"infinity")) nil)
                              ((string= depth-header "0") 0)
@@ -177,7 +177,7 @@ HEAD-REQUEST-P is true."
          (setf (header-out :content-language) content-language))
        (catch 'handler-done
          (handle-if-modified-since write-date)
-        (when (equal etag (header-in :if-none-match))
+        (when (equal etag (header-in* :if-none-match))
            (setf (return-code) +http-not-modified+)))
        (when (eql (return-code) +http-not-modified+)
          (throw 'handler-done nil))
@@ -219,7 +219,7 @@ instead."
  (defun delete-handler ()
    "The handler for DELETE requests.  Uses REMOVE-RESOURCE* to do
  the actual work."
-  (let ((depth-header (header-in :depth)))
+  (let ((depth-header (header-in* :depth)))
      (unless (or (null depth-header)
                  (string-equal depth-header "infinity"))
        (warn "Depth header is ~S." depth-header)
@@ -243,7 +243,7 @@ new resource from the contents sent by the client."
      (let ((parent (resource-parent resource)))
        (when (or (null parent) (not (resource-exists parent)))
          (conflict)))
-    (let* ((content-length-header (cdr (assoc :content-length  
(headers-in))))
+    (let* ((content-length-header (cdr (assoc :content-length  
(headers-in*))))
             (content-length (and content-length-header
                                  (parse-integer content-length- 
header :junk-allowed t))))
        (unless content-length
@@ -255,21 +255,21 @@ new resource from the contents sent by the  
client."
    "The handler for COPY requests which internally uses
  COPY-OR-MOVE-RESOURCE* to do the actual work.  Also doubles as a
  handler for MOVE requests if MOVEP is true."
-  (let* ((depth-header (header-in :depth))
+  (let* ((depth-header (header-in* :depth))
           (depth-value (cond ((or (null depth-header)
                                   (string-equal depth-header  
"infinity")) nil)
                              ((and (string= depth-header "0")
                                    (not movep)) 0)
                              (t (warn "Depth header is ~S." depth- 
header)
                                 (bad-request))))
-         (overwrite (equal (header-in :overwrite) "T"))
+         (overwrite (equal (header-in* :overwrite) "T"))
           (source (get-resource)))
      ;; note that we ignore a possible request body and thus the
      ;; "propertybehaviour" XML element for now - we just try to use
      ;; best effort to copy/move all properties
      (unless (resource-exists source)
        (not-found))
-    (let ((destination-header (header-in :destination)))
+    (let ((destination-header (header-in* :destination)))
        (unless destination-header
          (warn "No 'Destination' header.")
          (bad-request))
diff --git a/properties.lisp b/properties.lisp
index f0b0b28..49489c2 100755
--- a/properties.lisp
+++ b/properties.lisp
@@ -80,10 +80,10 @@ found) the property itself."
    (let ((property (handler-case
                        (get-property resource property-designator)
                      (error (condition)
-                      (log-message* "While trying to get property ~S  
for resource ~S: ~A"
-                                    (local-name property-designator)
-                                    (resource-script-name resource)
-                                    condition)
+                      (log-message "While trying to get property ~S  
for resource ~S: ~A"
+                                   (local-name property-designator)
+                                   (resource-script-name resource)
+                                   condition)
                        +http-internal-server-error+))))
      (etypecase property
        (null (values +http-ok+ property-designator))
diff --git a/resources.lisp b/resources.lisp
index 55cffdf..613667d 100755
--- a/resources.lisp
+++ b/resources.lisp
@@ -390,7 +390,7 @@ name SCRIPT-NAME \(which is already URL-decoded).")
     (make-instance resource-class-name
                    :script-name script-name)))

-(defun get-resource (&optional (script-name (url-decode* (script- 
name))))
+(defun get-resource (&optional (script-name (url-decode* (script- 
name*))))
    "Creates and returns an object of the type stored in
  *RESOURCE-CLASS* corresponding to the script name SCRIPT-NAME."
    (create-resource *resource-class* script-name))
diff --git a/specials.lisp b/specials.lisp
index f4fefc7..2bfb12f 100755
--- a/specials.lisp
+++ b/specials.lisp
@@ -36,6 +36,10 @@
      `(cl:defconstant ,name (if (boundp ',name) (symbol-value  
',name) ,value)
         ,@(when doc (list doc)))))

+(defun constantly-nil (&rest args)
+  (declare (ignore args))
+  nil)
+
  (defconstant +dav-property-alist+
    `(("creationdate" . creation-date)
      ("displayname" . resource-display-name)
@@ -46,8 +50,8 @@
      ("getcontentlanguage" . resource-content-language)
      ("resourcetype" . resource-type)
      ("source" . resource-source)
-    ("lockdiscovery" . ,(constantly nil))
-    ("supportedlock" . ,(constantly nil)))
+    ("lockdiscovery" . constantly-nil)
+    ("supportedlock" . constantly-nil))
    "An alist mapping the \(names of the) standard DAV properties
  to functions handling them.")

diff --git a/util.lisp b/util.lisp
index 85b3afd..4f85165 100755
--- a/util.lisp
+++ b/util.lisp
@@ -90,5 +90,5 @@ then uses LATIN-1 if that fails."
    ;; LATIN-1...
    (handler-case
        (url-decode string +utf-8+)
-    (flex:flexi-stream-encoding-error ()
+    (flex:external-format-encoding-error ()
        (url-decode string +latin-1+))))





From ch-tbnl at bobobeach.com  Mon Jun 23 23:47:41 2008
From: ch-tbnl at bobobeach.com (Cyrus Harmon)
Date: Mon, 23 Jun 2008 16:47:41 -0700
Subject: [hunchentoot-devel] cl-webdav errors
In-Reply-To: <E353823A-DE61-4BBA-AC50-105DE43FE98A@bobobeach.com>
References: <73D0B298-A665-4800-8E6C-1E6AF31C906D@bobobeach.com>
	<uod5rn3my.fsf@agharta.de>
	<E353823A-DE61-4BBA-AC50-105DE43FE98A@bobobeach.com>
Message-ID: <08F96696-B73C-4907-99AC-42FE3C3E1E37@bobobeach.com>


Now I get the following:

[2008-06-23 16:38:23 [ERROR]] The value of HUNCHENTOOT::NEW-VALUE is  
NIL, which is not of type STRING.
0: (SB-DEBUG::MAP-BACKTRACE #<CLOSURE (LAMBDA #) {11DC2185}>)[:EXTERNAL]
1: (BACKTRACE 536870911 #<SB-IMPL::STRING-OUTPUT-STREAM {11DC2121}>)
2: (HUNCHENTOOT:GET-BACKTRACE #<unavailable argument>)
3: ((FLET #:LAMBDA452) #<SIMPLE-TYPE-ERROR {11DC1DA9}>)
4: (SIGNAL #<SIMPLE-TYPE-ERROR {11DC1DA9}>)[:EXTERNAL]
5: (ERROR #<SIMPLE-TYPE-ERROR {11DC1DA9}>)[:EXTERNAL]
6: (SB-KERNEL:CHECK-TYPE-ERROR HUNCHENTOOT::NEW-VALUE NIL STRING NIL)
7: ((SB-PCL::FAST-METHOD (SETF HUNCHENTOOT:HEADER-OUT) :AFTER
      (T (EQL :CONTENT-TYPE)))
     #<unused argument>
     #<unused argument>
     #<unavailable argument>
     #<unused argument>
     #<HUNCHENTOOT::REPLY {11DBEDC1}>)
8: ((LAMBDA
         (SB-PCL::.PV. SB-PCL::.NEXT-METHOD-CALL. SB-PCL::.ARG0. SB- 
PCL::.ARG1.
          SB-INT:&MORE SB-PCL::.DFUN-MORE-CONTEXT. SB-PCL::.DFUN-MORE- 
COUNT.))
     #<unused argument>
     #<unused argument>
     NIL
     :CONTENT-TYPE
     32810581
     1)
9: (CL-WEBDAV:OPTIONS-HANDLER)
10: ((LAMBDA ()))
11: (HUNCHENTOOT::PROCESS-REQUEST #<HUNCHENTOOT:REQUEST {11DC1AA9}>)
12: ((SB-PCL::FAST-METHOD HUNCHENTOOT::PROCESS-CONNECTION (T T))
      #<unavailable argument>
      #<unavailable argument>
      #<HUNCHENTOOT::SERVER (host *, port 4242)>
      #<USOCKET:STREAM-USOCKET {11DB9CA1}>)
13: ((SB-PCL::FAST-METHOD HUNCHENTOOT::PROCESS-CONNECTION :AROUND (T T))
      #<unavailable argument>
      #S(SB-PCL::FAST-METHOD-CALL
         :FUNCTION #<FUNCTION #>
         :PV NIL
         :NEXT-METHOD-CALL NIL
         :ARG-INFO (2))
      #<HUNCHENTOOT::SERVER (host *, port 4242)>
      #<USOCKET:STREAM-USOCKET {11DB9CA1}>)
14: ((FLET SB-THREAD::WITH-MUTEX-THUNK))
15: ((FLET #:WITHOUT-INTERRUPTS-BODY-[CALL-WITH-MUTEX]479))
16: (SB-THREAD::CALL-WITH-MUTEX
      #<CLOSURE (FLET SB-THREAD::WITH-MUTEX-THUNK) {7D29DA5}>
      #S(SB-THREAD:MUTEX
         :NAME "thread result lock"
         :%OWNER #<SB-THREAD:THREAD "Hunchentoot worker (client:  
127.0.0.1:59658)" RUNNING {11DBCE49}>
         :LUTEX #<unknown pointer object, widetag=#x5E {11DBCE17}>)
      #<SB-THREAD:THREAD "Hunchentoot worker (client:  
127.0.0.1:59658)" RUNNING {11DBCE49}>
      T)
17: ((LAMBDA ()))
18: ("foreign function: call_into_lisp")
19: ("foreign function: funcall0")
20: ("foreign function: new_thread_trampoline")
21: ("foreign function: _pthread_start")
22: ("foreign function: thread_start")


still digging...

Cyrus

On Jun 23, 2008, at 4:36 PM, Cyrus Harmon wrote:

>
> On Jun 23, 2008, at 4:16 PM, Edi Weitz wrote:
>
>> On Mon, 23 Jun 2008 15:50:27 -0700, Cyrus Harmon <ch-tbnl at bobobeach.com 
>> > wrote:
>>
>>> I'm getting some errors attempting to build the latest cl-webdav
>>> with the latest ediware/sbcl combo.
>>
>> Yes, that's to be expected.  I haven't looked at cl-webdav in the  
>> last
>> months.
>
> Hmm... ok.
>
>>> are we attempting to do something out of the CL spec here or is SBCL
>>> choking on legal code?
>>
>> I think SBCL is right.  (CONSTANTLY NIL) should be replaced by the
>> name of a function which does the same.
>
> Alright, I'm taking a stab at getting this to work then. It sort  
> builds now, but doesn't work.
>
> In an effort to figure out why not, I've discovered that tbnl:*catch- 
> errors-p* is still exported but doesn't exist anymore.
>
>
> Here's my first cut at things:
>
>
> diff --git a/handlers.lisp b/handlers.lisp
> index 8f00ea6..2facb08 100755
> --- a/handlers.lisp
> +++ b/handlers.lisp
> @@ -91,7 +91,7 @@ determined by *ALLOWED-METHODS* and *DAV- 
> COMPLIANCE-CLASSES*."
> content body \(if there is one) and returns a corresponding
> \"multistatus\" XML element using the methods for live and dead
> properties."
> -  (let* ((depth-header (header-in :depth))
> +  (let* ((depth-header (header-in* :depth))
>          (depth-value (cond ((or (null depth-header)
>                                  (string-equal depth-header  
> "infinity")) nil)
>                             ((string= depth-header "0") 0)
> @@ -177,7 +177,7 @@ HEAD-REQUEST-P is true."
>         (setf (header-out :content-language) content-language))
>       (catch 'handler-done
>         (handle-if-modified-since write-date)
> -        (when (equal etag (header-in :if-none-match))
> +        (when (equal etag (header-in* :if-none-match))
>           (setf (return-code) +http-not-modified+)))
>       (when (eql (return-code) +http-not-modified+)
>         (throw 'handler-done nil))
> @@ -219,7 +219,7 @@ instead."
> (defun delete-handler ()
>   "The handler for DELETE requests.  Uses REMOVE-RESOURCE* to do
> the actual work."
> -  (let ((depth-header (header-in :depth)))
> +  (let ((depth-header (header-in* :depth)))
>     (unless (or (null depth-header)
>                 (string-equal depth-header "infinity"))
>       (warn "Depth header is ~S." depth-header)
> @@ -243,7 +243,7 @@ new resource from the contents sent by the  
> client."
>     (let ((parent (resource-parent resource)))
>       (when (or (null parent) (not (resource-exists parent)))
>         (conflict)))
> -    (let* ((content-length-header (cdr (assoc :content-length  
> (headers-in))))
> +    (let* ((content-length-header (cdr (assoc :content-length  
> (headers-in*))))
>            (content-length (and content-length-header
>                                 (parse-integer content-length- 
> header :junk-allowed t))))
>       (unless content-length
> @@ -255,21 +255,21 @@ new resource from the contents sent by the  
> client."
>   "The handler for COPY requests which internally uses
> COPY-OR-MOVE-RESOURCE* to do the actual work.  Also doubles as a
> handler for MOVE requests if MOVEP is true."
> -  (let* ((depth-header (header-in :depth))
> +  (let* ((depth-header (header-in* :depth))
>          (depth-value (cond ((or (null depth-header)
>                                  (string-equal depth-header  
> "infinity")) nil)
>                             ((and (string= depth-header "0")
>                                   (not movep)) 0)
>                             (t (warn "Depth header is ~S." depth- 
> header)
>                                (bad-request))))
> -         (overwrite (equal (header-in :overwrite) "T"))
> +         (overwrite (equal (header-in* :overwrite) "T"))
>          (source (get-resource)))
>     ;; note that we ignore a possible request body and thus the
>     ;; "propertybehaviour" XML element for now - we just try to use
>     ;; best effort to copy/move all properties
>     (unless (resource-exists source)
>       (not-found))
> -    (let ((destination-header (header-in :destination)))
> +    (let ((destination-header (header-in* :destination)))
>       (unless destination-header
>         (warn "No 'Destination' header.")
>         (bad-request))
> diff --git a/properties.lisp b/properties.lisp
> index f0b0b28..49489c2 100755
> --- a/properties.lisp
> +++ b/properties.lisp
> @@ -80,10 +80,10 @@ found) the property itself."
>   (let ((property (handler-case
>                       (get-property resource property-designator)
>                     (error (condition)
> -                      (log-message* "While trying to get property  
> ~S for resource ~S: ~A"
> -                                    (local-name property-designator)
> -                                    (resource-script-name resource)
> -                                    condition)
> +                      (log-message "While trying to get property ~S  
> for resource ~S: ~A"
> +                                   (local-name property-designator)
> +                                   (resource-script-name resource)
> +                                   condition)
>                       +http-internal-server-error+))))
>     (etypecase property
>       (null (values +http-ok+ property-designator))
> diff --git a/resources.lisp b/resources.lisp
> index 55cffdf..613667d 100755
> --- a/resources.lisp
> +++ b/resources.lisp
> @@ -390,7 +390,7 @@ name SCRIPT-NAME \(which is already URL- 
> decoded).")
>    (make-instance resource-class-name
>                   :script-name script-name)))
>
> -(defun get-resource (&optional (script-name (url-decode* (script- 
> name))))
> +(defun get-resource (&optional (script-name (url-decode* (script- 
> name*))))
>   "Creates and returns an object of the type stored in
> *RESOURCE-CLASS* corresponding to the script name SCRIPT-NAME."
>   (create-resource *resource-class* script-name))
> diff --git a/specials.lisp b/specials.lisp
> index f4fefc7..2bfb12f 100755
> --- a/specials.lisp
> +++ b/specials.lisp
> @@ -36,6 +36,10 @@
>     `(cl:defconstant ,name (if (boundp ',name) (symbol-value  
> ',name) ,value)
>        ,@(when doc (list doc)))))
>
> +(defun constantly-nil (&rest args)
> +  (declare (ignore args))
> +  nil)
> +
> (defconstant +dav-property-alist+
>   `(("creationdate" . creation-date)
>     ("displayname" . resource-display-name)
> @@ -46,8 +50,8 @@
>     ("getcontentlanguage" . resource-content-language)
>     ("resourcetype" . resource-type)
>     ("source" . resource-source)
> -    ("lockdiscovery" . ,(constantly nil))
> -    ("supportedlock" . ,(constantly nil)))
> +    ("lockdiscovery" . constantly-nil)
> +    ("supportedlock" . constantly-nil))
>   "An alist mapping the \(names of the) standard DAV properties
> to functions handling them.")
>
> diff --git a/util.lisp b/util.lisp
> index 85b3afd..4f85165 100755
> --- a/util.lisp
> +++ b/util.lisp
> @@ -90,5 +90,5 @@ then uses LATIN-1 if that fails."
>   ;; LATIN-1...
>   (handler-case
>       (url-decode string +utf-8+)
> -    (flex:flexi-stream-encoding-error ()
> +    (flex:external-format-encoding-error ()
>       (url-decode string +latin-1+))))
>
>
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel



From ch-tbnl at bobobeach.com  Tue Jun 24 05:05:31 2008
From: ch-tbnl at bobobeach.com (Cyrus Harmon)
Date: Mon, 23 Jun 2008 22:05:31 -0700
Subject: [hunchentoot-devel] cl-webdav errors
In-Reply-To: <08F96696-B73C-4907-99AC-42FE3C3E1E37@bobobeach.com>
References: <73D0B298-A665-4800-8E6C-1E6AF31C906D@bobobeach.com>
	<uod5rn3my.fsf@agharta.de>
	<E353823A-DE61-4BBA-AC50-105DE43FE98A@bobobeach.com>
	<08F96696-B73C-4907-99AC-42FE3C3E1E37@bobobeach.com>
Message-ID: <5D5B62F7-7532-46F9-9074-33E9FBAE24B0@bobobeach.com>


The following patch (along with the patch from the pervious email)  
fixes the error I was seeing before:


diff --git a/handlers.lisp b/handlers.lisp
index 8f00ea6..ccc25b7 100755
--- a/handlers.lisp
+++ b/handlers.lisp
@@ -78,8 +78,7 @@ is needed to work around problems with some  
Microsoft DAV clients.")
  (defun options-handler ()
    "The handler for OPTIONS requests.  Output is basically
  determined by *ALLOWED-METHODS* and *DAV-COMPLIANCE-CLASSES*."
-  (setf (content-type) nil
-        (header-out :allow) (format nil "~{~A~^, ~}" *allowed-methods*)
+  (setf (header-out :allow) (format nil "~{~A~^, ~}" *allowed-methods*)
          (header-out :dav) (format nil "~{~D~^,~}" *dav-compliance- 
classes*)
          ;; Win2k wants this - sigh...
          (header-out :ms-author-via) "DAV")


This gets cl-webdav (at least for the trivial stuff I tried) working  
again on the new hunchentoot code.

Cyrus

On Jun 23, 2008, at 4:47 PM, Cyrus Harmon wrote:

>
> Now I get the following:
>
> [2008-06-23 16:38:23 [ERROR]] The value of HUNCHENTOOT::NEW-VALUE is  
> NIL, which is not of type STRING.
> 0: (SB-DEBUG::MAP-BACKTRACE #<CLOSURE (LAMBDA #) {11DC2185}>) 
> [:EXTERNAL]
> 1: (BACKTRACE 536870911 #<SB-IMPL::STRING-OUTPUT-STREAM {11DC2121}>)
> 2: (HUNCHENTOOT:GET-BACKTRACE #<unavailable argument>)
> 3: ((FLET #:LAMBDA452) #<SIMPLE-TYPE-ERROR {11DC1DA9}>)
> 4: (SIGNAL #<SIMPLE-TYPE-ERROR {11DC1DA9}>)[:EXTERNAL]
> 5: (ERROR #<SIMPLE-TYPE-ERROR {11DC1DA9}>)[:EXTERNAL]
> 6: (SB-KERNEL:CHECK-TYPE-ERROR HUNCHENTOOT::NEW-VALUE NIL STRING NIL)
> 7: ((SB-PCL::FAST-METHOD (SETF HUNCHENTOOT:HEADER-OUT) :AFTER
>     (T (EQL :CONTENT-TYPE)))
>    #<unused argument>
>    #<unused argument>
>    #<unavailable argument>
>    #<unused argument>
>    #<HUNCHENTOOT::REPLY {11DBEDC1}>)
> 8: ((LAMBDA
>        (SB-PCL::.PV. SB-PCL::.NEXT-METHOD-CALL. SB-PCL::.ARG0. SB- 
> PCL::.ARG1.
>         SB-INT:&MORE SB-PCL::.DFUN-MORE-CONTEXT. SB-PCL::.DFUN-MORE- 
> COUNT.))
>    #<unused argument>
>    #<unused argument>
>    NIL
>    :CONTENT-TYPE
>    32810581
>    1)
> 9: (CL-WEBDAV:OPTIONS-HANDLER)
> 10: ((LAMBDA ()))
> 11: (HUNCHENTOOT::PROCESS-REQUEST #<HUNCHENTOOT:REQUEST {11DC1AA9}>)
> 12: ((SB-PCL::FAST-METHOD HUNCHENTOOT::PROCESS-CONNECTION (T T))
>     #<unavailable argument>
>     #<unavailable argument>
>     #<HUNCHENTOOT::SERVER (host *, port 4242)>
>     #<USOCKET:STREAM-USOCKET {11DB9CA1}>)
> 13: ((SB-PCL::FAST-METHOD HUNCHENTOOT::PROCESS-CONNECTION :AROUND (T  
> T))
>     #<unavailable argument>
>     #S(SB-PCL::FAST-METHOD-CALL
>        :FUNCTION #<FUNCTION #>
>        :PV NIL
>        :NEXT-METHOD-CALL NIL
>        :ARG-INFO (2))
>     #<HUNCHENTOOT::SERVER (host *, port 4242)>
>     #<USOCKET:STREAM-USOCKET {11DB9CA1}>)
> 14: ((FLET SB-THREAD::WITH-MUTEX-THUNK))
> 15: ((FLET #:WITHOUT-INTERRUPTS-BODY-[CALL-WITH-MUTEX]479))
> 16: (SB-THREAD::CALL-WITH-MUTEX
>     #<CLOSURE (FLET SB-THREAD::WITH-MUTEX-THUNK) {7D29DA5}>
>     #S(SB-THREAD:MUTEX
>        :NAME "thread result lock"
>        :%OWNER #<SB-THREAD:THREAD "Hunchentoot worker (client:  
> 127.0.0.1:59658)" RUNNING {11DBCE49}>
>        :LUTEX #<unknown pointer object, widetag=#x5E {11DBCE17}>)
>     #<SB-THREAD:THREAD "Hunchentoot worker (client:  
> 127.0.0.1:59658)" RUNNING {11DBCE49}>
>     T)
> 17: ((LAMBDA ()))
> 18: ("foreign function: call_into_lisp")
> 19: ("foreign function: funcall0")
> 20: ("foreign function: new_thread_trampoline")
> 21: ("foreign function: _pthread_start")
> 22: ("foreign function: thread_start")
>
>
> still digging...
>
> Cyrus
>
> On Jun 23, 2008, at 4:36 PM, Cyrus Harmon wrote:
>
>>
>> On Jun 23, 2008, at 4:16 PM, Edi Weitz wrote:
>>
>>> On Mon, 23 Jun 2008 15:50:27 -0700, Cyrus Harmon <ch-tbnl at bobobeach.com 
>>> > wrote:
>>>
>>>> I'm getting some errors attempting to build the latest cl-webdav
>>>> with the latest ediware/sbcl combo.
>>>
>>> Yes, that's to be expected.  I haven't looked at cl-webdav in the  
>>> last
>>> months.
>>
>> Hmm... ok.
>>
>>>> are we attempting to do something out of the CL spec here or is  
>>>> SBCL
>>>> choking on legal code?
>>>
>>> I think SBCL is right.  (CONSTANTLY NIL) should be replaced by the
>>> name of a function which does the same.
>>
>> Alright, I'm taking a stab at getting this to work then. It sort  
>> builds now, but doesn't work.
>>
>> In an effort to figure out why not, I've discovered that  
>> tbnl:*catch-errors-p* is still exported but doesn't exist anymore.
>>
>>
>> Here's my first cut at things:
>>
>>
>> diff --git a/handlers.lisp b/handlers.lisp
>> index 8f00ea6..2facb08 100755
>> --- a/handlers.lisp
>> +++ b/handlers.lisp
>> @@ -91,7 +91,7 @@ determined by *ALLOWED-METHODS* and *DAV- 
>> COMPLIANCE-CLASSES*."
>> content body \(if there is one) and returns a corresponding
>> \"multistatus\" XML element using the methods for live and dead
>> properties."
>> -  (let* ((depth-header (header-in :depth))
>> +  (let* ((depth-header (header-in* :depth))
>>         (depth-value (cond ((or (null depth-header)
>>                                 (string-equal depth-header  
>> "infinity")) nil)
>>                            ((string= depth-header "0") 0)
>> @@ -177,7 +177,7 @@ HEAD-REQUEST-P is true."
>>        (setf (header-out :content-language) content-language))
>>      (catch 'handler-done
>>        (handle-if-modified-since write-date)
>> -        (when (equal etag (header-in :if-none-match))
>> +        (when (equal etag (header-in* :if-none-match))
>>          (setf (return-code) +http-not-modified+)))
>>      (when (eql (return-code) +http-not-modified+)
>>        (throw 'handler-done nil))
>> @@ -219,7 +219,7 @@ instead."
>> (defun delete-handler ()
>>  "The handler for DELETE requests.  Uses REMOVE-RESOURCE* to do
>> the actual work."
>> -  (let ((depth-header (header-in :depth)))
>> +  (let ((depth-header (header-in* :depth)))
>>    (unless (or (null depth-header)
>>                (string-equal depth-header "infinity"))
>>      (warn "Depth header is ~S." depth-header)
>> @@ -243,7 +243,7 @@ new resource from the contents sent by the  
>> client."
>>    (let ((parent (resource-parent resource)))
>>      (when (or (null parent) (not (resource-exists parent)))
>>        (conflict)))
>> -    (let* ((content-length-header (cdr (assoc :content-length  
>> (headers-in))))
>> +    (let* ((content-length-header (cdr (assoc :content-length  
>> (headers-in*))))
>>           (content-length (and content-length-header
>>                                (parse-integer content-length- 
>> header :junk-allowed t))))
>>      (unless content-length
>> @@ -255,21 +255,21 @@ new resource from the contents sent by the  
>> client."
>>  "The handler for COPY requests which internally uses
>> COPY-OR-MOVE-RESOURCE* to do the actual work.  Also doubles as a
>> handler for MOVE requests if MOVEP is true."
>> -  (let* ((depth-header (header-in :depth))
>> +  (let* ((depth-header (header-in* :depth))
>>         (depth-value (cond ((or (null depth-header)
>>                                 (string-equal depth-header  
>> "infinity")) nil)
>>                            ((and (string= depth-header "0")
>>                                  (not movep)) 0)
>>                            (t (warn "Depth header is ~S." depth- 
>> header)
>>                               (bad-request))))
>> -         (overwrite (equal (header-in :overwrite) "T"))
>> +         (overwrite (equal (header-in* :overwrite) "T"))
>>         (source (get-resource)))
>>    ;; note that we ignore a possible request body and thus the
>>    ;; "propertybehaviour" XML element for now - we just try to use
>>    ;; best effort to copy/move all properties
>>    (unless (resource-exists source)
>>      (not-found))
>> -    (let ((destination-header (header-in :destination)))
>> +    (let ((destination-header (header-in* :destination)))
>>      (unless destination-header
>>        (warn "No 'Destination' header.")
>>        (bad-request))
>> diff --git a/properties.lisp b/properties.lisp
>> index f0b0b28..49489c2 100755
>> --- a/properties.lisp
>> +++ b/properties.lisp
>> @@ -80,10 +80,10 @@ found) the property itself."
>>  (let ((property (handler-case
>>                      (get-property resource property-designator)
>>                    (error (condition)
>> -                      (log-message* "While trying to get property  
>> ~S for resource ~S: ~A"
>> -                                    (local-name property-designator)
>> -                                    (resource-script-name resource)
>> -                                    condition)
>> +                      (log-message "While trying to get property  
>> ~S for resource ~S: ~A"
>> +                                   (local-name property-designator)
>> +                                   (resource-script-name resource)
>> +                                   condition)
>>                      +http-internal-server-error+))))
>>    (etypecase property
>>      (null (values +http-ok+ property-designator))
>> diff --git a/resources.lisp b/resources.lisp
>> index 55cffdf..613667d 100755
>> --- a/resources.lisp
>> +++ b/resources.lisp
>> @@ -390,7 +390,7 @@ name SCRIPT-NAME \(which is already URL- 
>> decoded).")
>>   (make-instance resource-class-name
>>                  :script-name script-name)))
>>
>> -(defun get-resource (&optional (script-name (url-decode* (script- 
>> name))))
>> +(defun get-resource (&optional (script-name (url-decode* (script- 
>> name*))))
>>  "Creates and returns an object of the type stored in
>> *RESOURCE-CLASS* corresponding to the script name SCRIPT-NAME."
>>  (create-resource *resource-class* script-name))
>> diff --git a/specials.lisp b/specials.lisp
>> index f4fefc7..2bfb12f 100755
>> --- a/specials.lisp
>> +++ b/specials.lisp
>> @@ -36,6 +36,10 @@
>>    `(cl:defconstant ,name (if (boundp ',name) (symbol-value  
>> ',name) ,value)
>>       ,@(when doc (list doc)))))
>>
>> +(defun constantly-nil (&rest args)
>> +  (declare (ignore args))
>> +  nil)
>> +
>> (defconstant +dav-property-alist+
>>  `(("creationdate" . creation-date)
>>    ("displayname" . resource-display-name)
>> @@ -46,8 +50,8 @@
>>    ("getcontentlanguage" . resource-content-language)
>>    ("resourcetype" . resource-type)
>>    ("source" . resource-source)
>> -    ("lockdiscovery" . ,(constantly nil))
>> -    ("supportedlock" . ,(constantly nil)))
>> +    ("lockdiscovery" . constantly-nil)
>> +    ("supportedlock" . constantly-nil))
>>  "An alist mapping the \(names of the) standard DAV properties
>> to functions handling them.")
>>
>> diff --git a/util.lisp b/util.lisp
>> index 85b3afd..4f85165 100755
>> --- a/util.lisp
>> +++ b/util.lisp
>> @@ -90,5 +90,5 @@ then uses LATIN-1 if that fails."
>>  ;; LATIN-1...
>>  (handler-case
>>      (url-decode string +utf-8+)
>> -    (flex:flexi-stream-encoding-error ()
>> +    (flex:external-format-encoding-error ()
>>      (url-decode string +latin-1+))))
>>
>>
>>
>> _______________________________________________
>> tbnl-devel site list
>> tbnl-devel at common-lisp.net
>> http://common-lisp.net/mailman/listinfo/tbnl-devel
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel



From edi at agharta.de  Tue Jun 24 06:25:14 2008
From: edi at agharta.de (Edi Weitz)
Date: Tue, 24 Jun 2008 08:25:14 +0200
Subject: [hunchentoot-devel] cl-webdav errors
In-Reply-To: <5D5B62F7-7532-46F9-9074-33E9FBAE24B0@bobobeach.com> (Cyrus
	Harmon's message of "Mon, 23 Jun 2008 22:05:31 -0700")
References: <73D0B298-A665-4800-8E6C-1E6AF31C906D@bobobeach.com>
	<uod5rn3my.fsf@agharta.de>
	<E353823A-DE61-4BBA-AC50-105DE43FE98A@bobobeach.com>
	<08F96696-B73C-4907-99AC-42FE3C3E1E37@bobobeach.com>
	<5D5B62F7-7532-46F9-9074-33E9FBAE24B0@bobobeach.com>
Message-ID: <ud4m7mjsl.fsf@agharta.de>

On Mon, 23 Jun 2008 22:05:31 -0700, Cyrus Harmon <ch-tbnl at bobobeach.com> wrote:

> This gets cl-webdav (at least for the trivial stuff I tried) working
> again on the new hunchentoot code.

Thanks.  If you send the patches again with an email program that
works, I'll apply them and add the modified version of cl-webdav to
the "ediware" package at bknr.net.


From ch-tbnl at bobobeach.com  Tue Jun 24 13:02:23 2008
From: ch-tbnl at bobobeach.com (Cyrus Harmon)
Date: Tue, 24 Jun 2008 06:02:23 -0700
Subject: [hunchentoot-devel] cl-webdav errors
In-Reply-To: <ud4m7mjsl.fsf@agharta.de>
References: <73D0B298-A665-4800-8E6C-1E6AF31C906D@bobobeach.com>
	<uod5rn3my.fsf@agharta.de>
	<E353823A-DE61-4BBA-AC50-105DE43FE98A@bobobeach.com>
	<08F96696-B73C-4907-99AC-42FE3C3E1E37@bobobeach.com>
	<5D5B62F7-7532-46F9-9074-33E9FBAE24B0@bobobeach.com>
	<ud4m7mjsl.fsf@agharta.de>
Message-ID: <0D08BDF5-0AE3-461F-9FAA-93E29CC0AF5D@bobobeach.com>


Here's a revised git-patch.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: cl-webdav-fixes.patch
Type: application/octet-stream
Size: 6637 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20080624/99284fa0/attachment.obj>
-------------- next part --------------


Thanks,

Cyrus


On Jun 23, 2008, at 11:25 PM, Edi Weitz wrote:

> On Mon, 23 Jun 2008 22:05:31 -0700, Cyrus Harmon <ch-tbnl at bobobeach.com 
> > wrote:
>
>> This gets cl-webdav (at least for the trivial stuff I tried) working
>> again on the new hunchentoot code.
>
> Thanks.  If you send the patches again with an email program that
> works, I'll apply them and add the modified version of cl-webdav to
> the "ediware" package at bknr.net.
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel


From ch-tbnl at bobobeach.com  Tue Jun 24 21:24:04 2008
From: ch-tbnl at bobobeach.com (Cyrus Harmon)
Date: Tue, 24 Jun 2008 14:24:04 -0700
Subject: [hunchentoot-devel] script-name*
Message-ID: <A4507098-7E48-4EC0-9233-573713550045@bobobeach.com>

Well, it looks like Hans found the same problem I found with script- 
name, but, and this is a very minor stylistic point, since we already  
have the request here, why don't we just call (script-name request)  
instead of (script-name*)?

thanks,

Cyrus


Index: headers.lisp
===================================================================
--- headers.lisp	(revision 3320)
+++ headers.lisp	(working copy)
@@ -162,10 +162,10 @@
                             "The server could not verify that you are  
authorized to access the document requested.  Either you supplied the  
wrong credentials \(e.g., bad password), or your browser doesn't  
understand how to supply the credentials required.")
                            ((#.+http-forbidden+)
                             (format nil "You don't have permission to  
access ~A on this server."
-                                   (script-name*)))
+                                   (script-name request)))
                            ((#.+http-not-found+)
                             (format nil "The requested URL ~A was not  
found on this server."
-                                   (script-name*)))
+                                   (script-name request)))
                            ((#.+http-bad-request+)
                             "Your browser sent a request that this  
server could not understand.")
                            (otherwise ""))


instead of 


From hans at huebner.org  Wed Jun 25 07:43:06 2008
From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Wed, 25 Jun 2008 09:43:06 +0200
Subject: [hunchentoot-devel] script-name*
In-Reply-To: <A4507098-7E48-4EC0-9233-573713550045@bobobeach.com>
References: <A4507098-7E48-4EC0-9233-573713550045@bobobeach.com>
Message-ID: <fd2982320806250043p4763b49ew47c8fcd943efb1c1@mail.gmail.com>

Fixed, thanks.

Hans

On Tue, Jun 24, 2008 at 11:24 PM, Cyrus Harmon <ch-tbnl at bobobeach.com> wrote:
> Well, it looks like Hans found the same problem I found with script-name,
> but, and this is a very minor stylistic point, since we already have the
> request here, why don't we just call (script-name request) instead of
> (script-name*)?
>
> thanks,
>
> Cyrus
>
>
> Index: headers.lisp
> ===================================================================
> --- headers.lisp        (revision 3320)
> +++ headers.lisp        (working copy)
> @@ -162,10 +162,10 @@
>                            "The server could not verify that you are
> authorized to access the document requested.  Either you supplied the wrong
> credentials \(e.g., bad password), or your browser doesn't understand how to
> supply the credentials required.")
>                           ((#.+http-forbidden+)
>                            (format nil "You don't have permission to access
> ~A on this server."
> -                                   (script-name*)))
> +                                   (script-name request)))
>                           ((#.+http-not-found+)
>                            (format nil "The requested URL ~A was not found
> on this server."
> -                                   (script-name*)))
> +                                   (script-name request)))
>                           ((#.+http-bad-request+)
>                            "Your browser sent a request that this server
> could not understand.")
>                           (otherwise ""))
>
>
> instead of_______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>


From edi at agharta.de  Wed Jun 25 08:07:47 2008
From: edi at agharta.de (Edi Weitz)
Date: Wed, 25 Jun 2008 10:07:47 +0200
Subject: [hunchentoot-devel] cl-webdav errors
In-Reply-To: <0D08BDF5-0AE3-461F-9FAA-93E29CC0AF5D@bobobeach.com> (Cyrus
	Harmon's message of "Tue, 24 Jun 2008 06:02:23 -0700")
References: <73D0B298-A665-4800-8E6C-1E6AF31C906D@bobobeach.com>
	<uod5rn3my.fsf@agharta.de>
	<E353823A-DE61-4BBA-AC50-105DE43FE98A@bobobeach.com>
	<08F96696-B73C-4907-99AC-42FE3C3E1E37@bobobeach.com>
	<5D5B62F7-7532-46F9-9074-33E9FBAE24B0@bobobeach.com>
	<ud4m7mjsl.fsf@agharta.de>
	<0D08BDF5-0AE3-461F-9FAA-93E29CC0AF5D@bobobeach.com>
Message-ID: <uprq6j5t8.fsf@agharta.de>

On Tue, 24 Jun 2008 06:02:23 -0700, Cyrus Harmon <ch-tbnl at bobobeach.com> wrote:

> Here's a revised git-patch.

Thanks, that's online on bknr.net now.  Note that your usage of
log-message was wrong.  I've fixed that as well.


From nimalan.mahendran at gmail.com  Wed Jun 25 16:37:46 2008
From: nimalan.mahendran at gmail.com (Nimalan Mahendran)
Date: Wed, 25 Jun 2008 09:37:46 -0700
Subject: [hunchentoot-devel] HT-AJAX website down
Message-ID: <f1f612650806250937k5d531146kf72b01110fab5600@mail.gmail.com>

Hello,

I'm trying to access the HT-AJAX website, but it seems to be
inaccessible from either the cliki link or the hunchentoot link:
http://www.cliki.net/HT-AJAX (http://pen.two-bytes.com/misc/ht-ajax.html)
http://www.weitz.de/hunchentoot/#example
(http://85.65.214.241/misc/ht-ajax.html)

I can ping pen.two-bytes.com and it resolves to 85.65.214.241, but
can't access the web server. Does anyone know whether the website has
been down for a long while, whether HT-AJAX is still maintained and if
there is an alternate location to get a copy of the library and
documentation?

Thanks!
-- 
Nimalan Mahendran


From nimalan.mahendran at gmail.com  Wed Jun 25 17:37:04 2008
From: nimalan.mahendran at gmail.com (Nimalan Mahendran)
Date: Wed, 25 Jun 2008 10:37:04 -0700
Subject: [hunchentoot-devel] Re: HT-AJAX website down
In-Reply-To: <f1f612650806250937k5d531146kf72b01110fab5600@mail.gmail.com>
References: <f1f612650806250937k5d531146kf72b01110fab5600@mail.gmail.com>
Message-ID: <f1f612650806251037l27e4d21fr43557edffdbbeef6@mail.gmail.com>

On Wed, Jun 25, 2008 at 9:37 AM, Nimalan Mahendran
<nimalan.mahendran at gmail.com> wrote:
> Hello,
>
> I'm trying to access the HT-AJAX website, but it seems to be
> inaccessible from either the cliki link or the hunchentoot link:
> http://www.cliki.net/HT-AJAX (http://pen.two-bytes.com/misc/ht-ajax.html)
> http://www.weitz.de/hunchentoot/#example
> (http://85.65.214.241/misc/ht-ajax.html)
>
> I can ping pen.two-bytes.com and it resolves to 85.65.214.241, but
> can't access the web server. Does anyone know whether the website has
> been down for a long while, whether HT-AJAX is still maintained and if
> there is an alternate location to get a copy of the library and
> documentation?
>
> Thanks!
> --
> Nimalan Mahendran
>

Hello again,

It looks like it's back up!

Thanks,
-- 
Nimalan Mahendran


From urym at two-bytes.com  Wed Jun 25 21:18:31 2008
From: urym at two-bytes.com (Ury Marshak)
Date: Thu, 26 Jun 2008 00:18:31 +0300
Subject: [hunchentoot-devel] HT-AJAX website down
In-Reply-To: <f1f612650806250937k5d531146kf72b01110fab5600@mail.gmail.com>
References: <f1f612650806250937k5d531146kf72b01110fab5600@mail.gmail.com>
Message-ID: <4862B627.1010001@two-bytes.com>

Nimalan Mahendran wrote:
> Hello,
>
> I'm trying to access the HT-AJAX website, but it seems to be
> inaccessible 
Sorry about that, weird hardware glitch, the machine refused to boot for
a while.

> from either the cliki link or the hunchentoot link:
> http://www.cliki.net/HT-AJAX (http://pen.two-bytes.com/misc/ht-ajax.html)
> http://www.weitz.de/hunchentoot/#example
> (http://85.65.214.241/misc/ht-ajax.html)
>   
The Hunchentoot documentation points to the old address, that's entirely
my fault, forgot
about it when I've moved the files. So, if I might use the occasion to
ask Edi to change the
link in the Hunchentoot doc to point to the new address (as on cliki):
http://pen.two-bytes.com/misc/ht-ajax.html

> I can ping pen.two-bytes.com and it resolves to 85.65.214.241,
Actually it should resolve to ...214.242
If for you it's resolving to ...214.241 please let me know (off-list)

Regards,
Ury



From jeffrey at cunningham.net  Thu Jun 26 04:08:49 2008
From: jeffrey at cunningham.net (Jeff Cunningham)
Date: Wed, 25 Jun 2008 21:08:49 -0700
Subject: [hunchentoot-devel] No timestamp in access log?
Message-ID: <48631651.9070304@cunningham.net>


This may have come up already and I missed it, but after upgrading to 
the new ediware version of hunchentoot I've noticed that my access logs 
no longer have timestamps, whereas the error logs still do. 
Cross-correlating them is, needless to say, a challenge. Looking at the 
code it doesn't appear to have the capability without modification. What 
is the thought here?

--Jeff


From hans at huebner.org  Thu Jun 26 05:44:23 2008
From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Thu, 26 Jun 2008 07:44:23 +0200
Subject: [hunchentoot-devel] No timestamp in access log?
In-Reply-To: <48631651.9070304@cunningham.net>
References: <48631651.9070304@cunningham.net>
Message-ID: <fd2982320806252244l4699272bmce56bd472d58b373@mail.gmail.com>

On Thu, Jun 26, 2008 at 6:08 AM, Jeff Cunningham <jeffrey at cunningham.net> wrote:
>
> This may have come up already and I missed it, but after upgrading to the
> new ediware version of hunchentoot I've noticed that my access logs no
> longer have timestamps, whereas the error logs still do. Cross-correlating
> them is, needless to say, a challenge. Looking at the code it doesn't appear
> to have the capability without modification. What is the thought here?

This is a bug, thank you for reporting it.  I will fix it later today.

-Hans


From hans at huebner.org  Thu Jun 26 07:23:47 2008
From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Thu, 26 Jun 2008 09:23:47 +0200
Subject: [hunchentoot-devel] No timestamp in access log?
In-Reply-To: <fd2982320806252244l4699272bmce56bd472d58b373@mail.gmail.com>
References: <48631651.9070304@cunningham.net>
	<fd2982320806252244l4699272bmce56bd472d58b373@mail.gmail.com>
Message-ID: <fd2982320806260023q611fc29h9078b810fd446baf@mail.gmail.com>

A timestamp is now printed in the access log again.

-Hans

On Thu, Jun 26, 2008 at 7:44 AM, Hans H?bner <hans at huebner.org> wrote:
> On Thu, Jun 26, 2008 at 6:08 AM, Jeff Cunningham <jeffrey at cunningham.net> wrote:
>>
>> This may have come up already and I missed it, but after upgrading to the
>> new ediware version of hunchentoot I've noticed that my access logs no
>> longer have timestamps, whereas the error logs still do. Cross-correlating
>> them is, needless to say, a challenge. Looking at the code it doesn't appear
>> to have the capability without modification. What is the thought here?
>
> This is a bug, thank you for reporting it.  I will fix it later today.
>
> -Hans
>


From edi at agharta.de  Thu Jun 26 07:26:45 2008
From: edi at agharta.de (Edi Weitz)
Date: Thu, 26 Jun 2008 09:26:45 +0200
Subject: [hunchentoot-devel] HT-AJAX website down
In-Reply-To: <4862B627.1010001@two-bytes.com> (Ury Marshak's message of
	"Thu, 26 Jun 2008 00:18:31 +0300")
References: <f1f612650806250937k5d531146kf72b01110fab5600@mail.gmail.com>
	<4862B627.1010001@two-bytes.com>
Message-ID: <u63rwbqru.fsf@agharta.de>

On Thu, 26 Jun 2008 00:18:31 +0300, Ury Marshak <urym at two-bytes.com> wrote:

> So, if I might use the occasion to ask Edi to change the link in the
> Hunchentoot doc to point to the new address (as on cliki):
> http://pen.two-bytes.com/misc/ht-ajax.html

Has already been in the dev version for quite some time:

  http://bknr.net/trac/browser/trunk/thirdparty/hunchentoot/doc/index.xml

Looks like I forgot to update the release version, though.


From jeffrey at cunningham.net  Thu Jun 26 14:01:46 2008
From: jeffrey at cunningham.net (Jeff Cunningham)
Date: Thu, 26 Jun 2008 07:01:46 -0700
Subject: [hunchentoot-devel] No timestamp in access log?
In-Reply-To: <fd2982320806260023q611fc29h9078b810fd446baf@mail.gmail.com>
References: <48631651.9070304@cunningham.net>	<fd2982320806252244l4699272bmce56bd472d58b373@mail.gmail.com>
	<fd2982320806260023q611fc29h9078b810fd446baf@mail.gmail.com>
Message-ID: <4863A14A.5070806@cunningham.net>


Thanks.

By the way, I vote three thumbs up for the ediware svn access. It really 
simplifies keeping multiple systems up to date.

--Jeff

Hans H?bner wrote:
> A timestamp is now printed in the access log again.
>
> -Hans
>
> On Thu, Jun 26, 2008 at 7:44 AM, Hans H?bner <hans at huebner.org> wrote:
>   
>> On Thu, Jun 26, 2008 at 6:08 AM, Jeff Cunningham <jeffrey at cunningham.net> wrote:
>>     
>>> This may have come up already and I missed it, but after upgrading to the
>>> new ediware version of hunchentoot I've noticed that my access logs no
>>> longer have timestamps, whereas the error logs still do. Cross-correlating
>>> them is, needless to say, a challenge. Looking at the code it doesn't appear
>>> to have the capability without modification. What is the thought here?
>>>       
>> This is a bug, thank you for reporting it.  I will fix it later today.
>>
>> -Hans
>>
>>     
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>
>   


From ch-tbnl at bobobeach.com  Fri Jun 27 02:58:08 2008
From: ch-tbnl at bobobeach.com (Cyrus Harmon)
Date: Thu, 26 Jun 2008 19:58:08 -0700
Subject: [hunchentoot-devel] cl-webdav level 2 support patch
Message-ID: <09C96236-60FA-4DD5-83A5-2123119DEA81@bobobeach.com>


The attached patch provides initial support for DAV level 2, including  
locking and unlocking of files and enables cl-webdav servers to be  
used by the MacOS WebDAVFS client.

Code review/comments greatly appreciated.

thanks,

Cyrus

-------------- next part --------------
A non-text attachment was scrubbed...
Name: cl-webdav-lock-support-2.patch
Type: application/octet-stream
Size: 17544 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20080626/d32c0711/attachment.obj>
-------------- next part --------------



From ch-tbnl at bobobeach.com  Fri Jun 27 03:03:02 2008
From: ch-tbnl at bobobeach.com (Cyrus Harmon)
Date: Thu, 26 Jun 2008 20:03:02 -0700
Subject: [hunchentoot-devel] cl-webdav level 2 support patch
In-Reply-To: <09C96236-60FA-4DD5-83A5-2123119DEA81@bobobeach.com>
References: <09C96236-60FA-4DD5-83A5-2123119DEA81@bobobeach.com>
Message-ID: <9D8EA715-A2AC-4DF8-80C2-D5263F49967B@bobobeach.com>


Oh, I neglected to mention that, since I'm lazy, I used cxml-stp for  
some of the xml handling stuff, which currently, although not  
necessarily for all time, requires plexxipus-xpath, so, since that was  
already there, I went ahead and used the xpath stuff for some of the  
XML handling. All of this could probably be done with Edi's existing  
XML handling or the built-in cxml stuff, but this was the most  
expedient. I can certainly understand if there is a desire to not have  
cl-webdav depend on an xpath implementation.

Cyrus

On Jun 26, 2008, at 7:58 PM, Cyrus Harmon wrote:

>
> The attached patch provides initial support for DAV level 2,  
> including locking and unlocking of files and enables cl-webdav  
> servers to be used by the MacOS WebDAVFS client.
>
> Code review/comments greatly appreciated.
>
> thanks,
>
> Cyrus
>
> <cl-webdav-lock-support-2.patch>
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel



From ch-tbnl at bobobeach.com  Fri Jun 27 03:24:58 2008
From: ch-tbnl at bobobeach.com (Cyrus Harmon)
Date: Thu, 26 Jun 2008 20:24:58 -0700
Subject: [hunchentoot-devel] cl-webdav level 2 support patch
In-Reply-To: <9D8EA715-A2AC-4DF8-80C2-D5263F49967B@bobobeach.com>
References: <09C96236-60FA-4DD5-83A5-2123119DEA81@bobobeach.com>
	<9D8EA715-A2AC-4DF8-80C2-D5263F49967B@bobobeach.com>
Message-ID: <47BADFA2-48F2-4D82-AA54-2401D981DC05@bobobeach.com>

Oh, and I further mentioned that this doesn't quite work. There are  
some file major file corruption issues on uploaded files. I think. Not  
sure where the problem lies yet...

sorry for the false alarm.

cyrus

On Jun 26, 2008, at 8:03 PM, Cyrus Harmon wrote:

>
> Oh, I neglected to mention that, since I'm lazy, I used cxml-stp for  
> some of the xml handling stuff, which currently, although not  
> necessarily for all time, requires plexxipus-xpath, so, since that  
> was already there, I went ahead and used the xpath stuff for some of  
> the XML handling. All of this could probably be done with Edi's  
> existing XML handling or the built-in cxml stuff, but this was the  
> most expedient. I can certainly understand if there is a desire to  
> not have cl-webdav depend on an xpath implementation.
>
> Cyrus
>
> On Jun 26, 2008, at 7:58 PM, Cyrus Harmon wrote:
>
>>
>> The attached patch provides initial support for DAV level 2,  
>> including locking and unlocking of files and enables cl-webdav  
>> servers to be used by the MacOS WebDAVFS client.
>>
>> Code review/comments greatly appreciated.
>>
>> thanks,
>>
>> Cyrus
>>
>> <cl-webdav-lock-support-2.patch>
>>
>> _______________________________________________
>> tbnl-devel site list
>> tbnl-devel at common-lisp.net
>> http://common-lisp.net/mailman/listinfo/tbnl-devel
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel



From ch-tbnl at bobobeach.com  Fri Jun 27 23:34:44 2008
From: ch-tbnl at bobobeach.com (Cyrus Harmon)
Date: Fri, 27 Jun 2008 16:34:44 -0700
Subject: [hunchentoot-devel] chunked encoding for input
Message-ID: <91F6D7D3-3319-43DA-92D2-E91B6F02EB4F@bobobeach.com>


The following patch fixes the case where one sends chunked data to a  
hunchentoot server with, say, a PUT request. We weren't paying  
attention to the transfer-encoding in get-post-data.

Also, we should support looking for both "chunked" and "Chunked", so I  
use string-equal instead of equalp here.

thanks,

Cyrus

-------------- next part --------------
A non-text attachment was scrubbed...
Name: hunchentoot-chunked-encoding.patch
Type: application/octet-stream
Size: 1898 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20080627/cbf5e1fb/attachment.obj>
-------------- next part --------------


From edi at agharta.de  Fri Jun 27 23:46:27 2008
From: edi at agharta.de (Edi Weitz)
Date: Sat, 28 Jun 2008 01:46:27 +0200
Subject: [hunchentoot-devel] chunked encoding for input
In-Reply-To: <91F6D7D3-3319-43DA-92D2-E91B6F02EB4F@bobobeach.com> (Cyrus
	Harmon's message of "Fri, 27 Jun 2008 16:34:44 -0700")
References: <91F6D7D3-3319-43DA-92D2-E91B6F02EB4F@bobobeach.com>
Message-ID: <u63ruh25o.fsf@agharta.de>

On Fri, 27 Jun 2008 16:34:44 -0700, Cyrus Harmon <ch-tbnl at bobobeach.com> wrote:

> The following patch fixes the case where one sends chunked data to a
> hunchentoot server with, say, a PUT request. We weren't paying
> attention to the transfer-encoding in get-post-data.

Thanks for catching that.  This is essentially what is already done in
process-request, but due to the refactoring Hans and I did it happens
too late at that point.

I think get-post-data is not the right place for this, though.
Switching chunking on or off should happen "one level further up" so
to say.  I'll try to fix this over the weekend.

> Also, we should support looking for both "chunked" and "Chunked", so
> I use string-equal instead of equalp here.

equalp already does that... :)

Thanks,
Edi.


From edi at agharta.de  Fri Jun 27 23:48:46 2008
From: edi at agharta.de (Edi Weitz)
Date: Sat, 28 Jun 2008 01:48:46 +0200
Subject: [hunchentoot-devel] cl-webdav level 2 support patch
In-Reply-To: <09C96236-60FA-4DD5-83A5-2123119DEA81@bobobeach.com> (Cyrus
	Harmon's message of "Thu, 26 Jun 2008 19:58:08 -0700")
References: <09C96236-60FA-4DD5-83A5-2123119DEA81@bobobeach.com>
Message-ID: <u1w2ih21t.fsf@agharta.de>

On Thu, 26 Jun 2008 19:58:08 -0700, Cyrus Harmon <ch-tbnl at bobobeach.com> wrote:

> The attached patch provides initial support for DAV level 2,
> including locking and unlocking of files and enables cl-webdav
> servers to be used by the MacOS WebDAVFS client.
>
> Code review/comments greatly appreciated.

Thanks for that.  I don't have the time to review this at the moment,
but I think it's a great addition.  Due to the dependencies you
mentioned, I'd rather not add it to cl-webdav as is, though.  I'll
link to your patch from the cl-webdav website (remind me if I forget!)
for now.

Thanks,
Edi.


From ch-tbnl at bobobeach.com  Sat Jun 28 00:02:15 2008
From: ch-tbnl at bobobeach.com (Cyrus Harmon)
Date: Fri, 27 Jun 2008 17:02:15 -0700
Subject: [hunchentoot-devel] chunked encoding for input
In-Reply-To: <u63ruh25o.fsf@agharta.de>
References: <91F6D7D3-3319-43DA-92D2-E91B6F02EB4F@bobobeach.com>
	<u63ruh25o.fsf@agharta.de>
Message-ID: <988A24B6-2970-4FDF-8F09-4DD78559693A@bobobeach.com>


On Jun 27, 2008, at 4:46 PM, Edi Weitz wrote:

> On Fri, 27 Jun 2008 16:34:44 -0700, Cyrus Harmon <ch-tbnl at bobobeach.com 
> > wrote:
>
>> The following patch fixes the case where one sends chunked data to a
>> hunchentoot server with, say, a PUT request. We weren't paying
>> attention to the transfer-encoding in get-post-data.
>
> Thanks for catching that.  This is essentially what is already done in
> process-request, but due to the refactoring Hans and I did it happens
> too late at that point.
>
> I think get-post-data is not the right place for this, though.
> Switching chunking on or off should happen "one level further up" so
> to say.  I'll try to fix this over the weekend.

Ah, right. I see that it's the fact that this is an initarg to the  
request object that then gets passed to process-request that makes  
this tricky.

One hacky fix is to do:

--- server.lisp	(revision 3371)
+++ server.lisp	(working copy)
@@ -500,7 +500,8 @@
                (when (member "chunked" transfer-encodings :test  
#'equalp)
                  ;; turn chunking on before we read the request body
                  (setf *hunchentoot-stream* (make-chunked-stream  
*hunchentoot-stream*)
-                      (chunked-stream-input-chunking-p *hunchentoot- 
stream*) t))))
+                      (chunked-stream-input-chunking-p *hunchentoot- 
stream*) t
+                      (slot-value request 'content-stream)  
*hunchentoot-stream*))))
            (let* ((*request* request)
                   backtrace)
              (multiple-value-bind (body error)



>> Also, we should support looking for both "chunked" and "Chunked", so
>> I use string-equal instead of equalp here.
>
> equalp already does that... :)

d'oh!

thanks,

Cyrus




From edi at agharta.de  Sat Jun 28 08:51:08 2008
From: edi at agharta.de (Edi Weitz)
Date: Sat, 28 Jun 2008 10:51:08 +0200
Subject: [hunchentoot-devel] chunked encoding for input
In-Reply-To: <988A24B6-2970-4FDF-8F09-4DD78559693A@bobobeach.com> (Cyrus
	Harmon's message of "Fri, 27 Jun 2008 17:02:15 -0700")
References: <91F6D7D3-3319-43DA-92D2-E91B6F02EB4F@bobobeach.com>
	<u63ruh25o.fsf@agharta.de>
	<988A24B6-2970-4FDF-8F09-4DD78559693A@bobobeach.com>
Message-ID: <uskuyeydf.fsf@agharta.de>

On Fri, 27 Jun 2008 17:02:15 -0700, Cyrus Harmon <ch-tbnl at bobobeach.com> wrote:

> -                      (chunked-stream-input-chunking-p *hunchentoot- 
> stream*) t))))
> +                      (chunked-stream-input-chunking-p *hunchentoot- 
> stream*) t
> +                      (slot-value request 'content-stream)

You should get yourself a decent email client... :)


From jeffrey at cunningham.net  Sun Jun 29 23:31:47 2008
From: jeffrey at cunningham.net (Jeff Cunningham)
Date: Sun, 29 Jun 2008 16:31:47 -0700
Subject: [hunchentoot-devel] googlebot revisitation rate excessive?
Message-ID: <48681B63.40407@cunningham.net>


Has anyone else noticed excessive visitation of pages served dynamically 
by Hunchentoot? On a couple of small sites virtually every page gets hit 
every five minutes by http://www.google.com/bot.html, regular as clockwork.

Normally, I setup robots.txt to allow google to walk these sites but 
unless I can think of a way to tell them to back off to once a week or 
something I'm about to Disallow them. They're just little private sites 
and Google ends up being 99% of the traffic. It's silly.

--Jeff




From xach at xach.com  Sun Jun 29 23:33:17 2008
From: xach at xach.com (Zach Beane)
Date: Sun, 29 Jun 2008 19:33:17 -0400
Subject: [hunchentoot-devel] googlebot revisitation rate excessive?
In-Reply-To: <48681B63.40407@cunningham.net>
References: <48681B63.40407@cunningham.net>
Message-ID: <20080629233317.GB14673@xach.com>

On Sun, Jun 29, 2008 at 04:31:47PM -0700, Jeff Cunningham wrote:
> 
> Has anyone else noticed excessive visitation of pages served dynamically 
> by Hunchentoot? On a couple of small sites virtually every page gets hit 
> every five minutes by http://www.google.com/bot.html, regular as clockwork.
> 
> Normally, I setup robots.txt to allow google to walk these sites but 
> unless I can think of a way to tell them to back off to once a week or 
> something I'm about to Disallow them. They're just little private sites 
> and Google ends up being 99% of the traffic. It's silly.

FWIW, I haven't had any trouble like that with two different
Hunchentoot sites.

Zach


From stassats at gmail.com  Sun Jun 29 23:56:52 2008
From: stassats at gmail.com (Stas Boukarev)
Date: Mon, 30 Jun 2008 03:56:52 +0400
Subject: [hunchentoot-devel] googlebot revisitation rate excessive?
In-Reply-To: <48681B63.40407@cunningham.net>
References: <48681B63.40407@cunningham.net>
Message-ID: <9f0fec110806291656t39ea1b0byd8c3b39e5319a2d5@mail.gmail.com>

On 6/30/08, Jeff Cunningham <jeffrey at cunningham.net> wrote:
>
>  Has anyone else noticed excessive visitation of pages served dynamically by Hunchentoot?

My site is not very popular, and googlebot visits it from time to
time. The shortest interval was 36 hours.

-- 
With Best Regards, Stas.


From jeffrey at cunningham.net  Mon Jun 30 00:01:06 2008
From: jeffrey at cunningham.net (Jeff Cunningham)
Date: Sun, 29 Jun 2008 17:01:06 -0700
Subject: [hunchentoot-devel] googlebot revisitation rate excessive?
In-Reply-To: <20080629233317.GB14673@xach.com>
References: <48681B63.40407@cunningham.net> <20080629233317.GB14673@xach.com>
Message-ID: <48682242.4010205@cunningham.net>


Zach Beane wrote:
> On Sun, Jun 29, 2008 at 04:31:47PM -0700, Jeff Cunningham wrote:
>   
>> Has anyone else noticed excessive visitation of pages served dynamically 
>> by Hunchentoot? On a couple of small sites virtually every page gets hit 
>> every five minutes by http://www.google.com/bot.html, regular as clockwork.
>>
>> Normally, I setup robots.txt to allow google to walk these sites but 
>> unless I can think of a way to tell them to back off to once a week or 
>> something I'm about to Disallow them. They're just little private sites 
>> and Google ends up being 99% of the traffic. It's silly.
>>     
>
> FWIW, I haven't had any trouble like that with two different
> Hunchentoot sites.
>   
Is there something you do to indicate that the page has a fixed date? I 
was wondering if maybe the fact that dynamically generated pages look 
"changed" to Google, so they get thrown back in the queue to be rechecked.




From jeffrey at cunningham.net  Mon Jun 30 00:04:14 2008
From: jeffrey at cunningham.net (Jeff Cunningham)
Date: Sun, 29 Jun 2008 17:04:14 -0700
Subject: [hunchentoot-devel] googlebot revisitation rate excessive?
In-Reply-To: <9f0fec110806291656t39ea1b0byd8c3b39e5319a2d5@mail.gmail.com>
References: <48681B63.40407@cunningham.net>
	<9f0fec110806291656t39ea1b0byd8c3b39e5319a2d5@mail.gmail.com>
Message-ID: <486822FE.60109@cunningham.net>




Stas Boukarev wrote:
> On 6/30/08, Jeff Cunningham <jeffrey at cunningham.net> wrote:
>   
>>  Has anyone else noticed excessive visitation of pages served dynamically by Hunchentoot?
>>     
>
> My site is not very popular, and googlebot visits it from time to
> time. The shortest interval was 36 hours.
>
>   
Hmmm. Now I'm feeling real "special" and I'll be my sites are even less 
popular.



From xach at xach.com  Mon Jun 30 00:04:48 2008
From: xach at xach.com (Zach Beane)
Date: Sun, 29 Jun 2008 20:04:48 -0400
Subject: [hunchentoot-devel] googlebot revisitation rate excessive?
In-Reply-To: <48682242.4010205@cunningham.net>
References: <48681B63.40407@cunningham.net> <20080629233317.GB14673@xach.com>
	<48682242.4010205@cunningham.net>
Message-ID: <20080630000448.GD14673@xach.com>

On Sun, Jun 29, 2008 at 05:01:06PM -0700, Jeff Cunningham wrote:

> Is there something you do to indicate that the page has a fixed date? I 
> was wondering if maybe the fact that dynamically generated pages look 
> "changed" to Google, so they get thrown back in the queue to be rechecked.

Nope, I don't do anything like that.

Zach


From ctdean at sokitomi.com  Mon Jun 30 00:08:03 2008
From: ctdean at sokitomi.com (Chris Dean)
Date: Sun, 29 Jun 2008 17:08:03 -0700
Subject: [hunchentoot-devel] googlebot revisitation rate excessive?
In-Reply-To: <48681B63.40407@cunningham.net> (Jeff Cunningham's message of
	"Sun, 29 Jun 2008 16:31:47 -0700")
References: <48681B63.40407@cunningham.net>
Message-ID: <m2skuvlr8c.fsf@jacaranda.sokitomi.com>


> Normally, I setup robots.txt to allow google to walk these sites but
> unless I can think of a way to tell them to back off to once a week or
> something I'm about to Disallow them. They're just little private
> sites and Google ends up being 99% of the traffic. It's silly.

You can set the crawl rate on your site a couple of ways.  I think
(but am not sure) that Google supports the the Crawl-delay robots.txt
directive.  You can also set the googlebot rate for 90 days in the
Webmaster tools.

  http://www.google.com/support/webmasters/bin/answer.py?hl=en&answer=48620

BTW, I have not experienced this problem myself.

Cheers,
Chris Dean



From jeffrey at cunningham.net  Mon Jun 30 00:15:30 2008
From: jeffrey at cunningham.net (Jeff Cunningham)
Date: Sun, 29 Jun 2008 17:15:30 -0700
Subject: [hunchentoot-devel] googlebot revisitation rate excessive?
In-Reply-To: <20080630000448.GD14673@xach.com>
References: <48681B63.40407@cunningham.net>
	<20080629233317.GB14673@xach.com>	<48682242.4010205@cunningham.net>
	<20080630000448.GD14673@xach.com>
Message-ID: <486825A2.9060402@cunningham.net>




Zach Beane wrote:
> On Sun, Jun 29, 2008 at 05:01:06PM -0700, Jeff Cunningham wrote:
>
>   
>> Is there something you do to indicate that the page has a fixed date? I 
>> was wondering if maybe the fact that dynamically generated pages look 
>> "changed" to Google, so they get thrown back in the queue to be rechecked.
>>     
>
> Nope, I don't do anything like that.
>   

Well, here's another hypothesis: maybe Google isn't happy with the 
response it is getting from my sites. My error log shows this sequence:

[2008-06-29 16:25:23 [INFO]] No session for session identifier 
'491:2BB8EA11136C90E6BA7D7F466951E370' (User-Agent: 'Mozilla/5.0 
(compatible; Googlebot/2.1; +http://www.google.com/bot.html)', IP: 
'127.0.0.1')
[2008-06-29 16:25:23 [WARNING]] Warning while processing connection: 
Unexpected character , after <meta
[2008-06-29 16:25:43 [ERROR]] Error while processing connection: I/O 
timeout reading #<SB-SYS:FD-STREAM for "a socket" {195190D9}>.
[2008-06-29 16:27:27 [INFO]] No session for session identifier 
'481:C9244EC27C31213FFE797F9E2ABE1535' (User-Agent: 'Mozilla/5.0 
(compatible; Googlebot/2.1; +http://www.google.com/bot.html)', IP: 
'127.0.0.1')
[2008-06-29 16:27:27 [WARNING]] Warning while processing connection: 
Unexpected character , after <meta


I've looked high and low for bad syntax involving generation of a meta 
tag, but it isn't there. I think it is an artifact of the timeout or 
something. Anyway, I'm wondering if the googlebot doesn't like the 
response my server is giving it, doesn't respond, the server waits, 
times out, then finally the googlebot gets back to it and by that time 
the session identifier is bad. Any thoughts?

--Jeff

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


From ch-tbnl at bobobeach.com  Mon Jun 30 02:13:19 2008
From: ch-tbnl at bobobeach.com (Cyrus Harmon)
Date: Sun, 29 Jun 2008 19:13:19 -0700
Subject: [hunchentoot-devel] cl-webdav-level-2.asd?
Message-ID: <B7D745D6-155C-472F-AB45-ADF36010AAC8@bobobeach.com>

Edi et al.,

It seems like it would be pretty straightforward to move the cl-webdav- 
level-2 stuff into it's own asdf system.

There are a couple of things from my patch that should probably go  
into cl-webdav (and ht) as is, but most of it could easily moved to  
another package and still get the functionality we want.

The only tricky bits are the the handlers. How should we handle the  
bits that need to reach down into the existing propfind/get handlers?  
We could just redefine these with the copy/pasted/modified code in the  
new asdf system, but that seems like a hacky OAOO violation that is  
likely to lead to subtle bugs down the road. Some sort of CLOS hackery  
with around methods? A list of functions to call for each handler?  
Thoughts?

thanks,

Cyrus






From hans at huebner.org  Mon Jun 30 04:49:47 2008
From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Mon, 30 Jun 2008 06:49:47 +0200
Subject: [hunchentoot-devel] googlebot revisitation rate excessive?
In-Reply-To: <486825A2.9060402@cunningham.net>
References: <48681B63.40407@cunningham.net> <20080629233317.GB14673@xach.com>
	<48682242.4010205@cunningham.net> <20080630000448.GD14673@xach.com>
	<486825A2.9060402@cunningham.net>
Message-ID: <fd2982320806292149h71786fdbg9c52890f335572dc@mail.gmail.com>

On Mon, Jun 30, 2008 at 2:15 AM, Jeff Cunningham <jeffrey at cunningham.net> wrote:
> [2008-06-29 16:25:23 [INFO]] No session for session identifier
> '491:2BB8EA11136C90E6BA7D7F466951E370' (User-Agent: 'Mozilla/5.0
> (compatible; Googlebot/2.1; +http://www.google.com/bot.html)', IP:
> '127.0.0.1')
> [2008-06-29 16:25:23 [WARNING]] Warning while processing connection:
> Unexpected character , after <meta
> [2008-06-29 16:25:43 [ERROR]] Error while processing connection: I/O timeout
> reading #<SB-SYS:FD-STREAM for "a socket" {195190D9}>.
> [2008-06-29 16:27:27 [INFO]] No session for session identifier
> '481:C9244EC27C31213FFE797F9E2ABE1535' (User-Agent: 'Mozilla/5.0
> (compatible; Googlebot/2.1; +http://www.google.com/bot.html)', IP:
> '127.0.0.1')
> [2008-06-29 16:27:27 [WARNING]] Warning while processing connection:
> Unexpected character , after <meta
>
>
> I've looked high and low for bad syntax involving generation of a meta tag,
> but it isn't there. I think it is an artifact of the timeout or something.
> Anyway, I'm wondering if the googlebot doesn't like the response my server
> is giving it, doesn't respond, the server waits, times out, then finally the
> googlebot gets back to it and by that time the session identifier is bad.
> Any thoughts?

I'd set HUNCHENTOOT:*HEADER-STREAM* to *STANDARD-OUTPUT* and
*BREAK-ON-SIGNALS* to 'WARNING, then wait for the Googlebot request to
come in.  The headers printed to the console may give you a clue what
the request looks like and maybe a way to initiate such a failing
request yourself, maybe with Drakma or wget.  You'll may also be able
to get a clue from looking at the backtrace in a debugger.

I find it curious that Google retries every five minutes.  Did you
verify that the request is coming from a Google IP address?  It may
also be a prankster's script gone wild, in which case I'd block the IP
address.

Or ignore the issue.  The Internet _is_ silly, after all.

-Hans


From edi at agharta.de  Mon Jun 30 06:45:55 2008
From: edi at agharta.de (Edi Weitz)
Date: Mon, 30 Jun 2008 08:45:55 +0200
Subject: [hunchentoot-devel] cl-webdav-level-2.asd?
In-Reply-To: <B7D745D6-155C-472F-AB45-ADF36010AAC8@bobobeach.com> (Cyrus
	Harmon's message of "Sun, 29 Jun 2008 19:13:19 -0700")
References: <B7D745D6-155C-472F-AB45-ADF36010AAC8@bobobeach.com>
Message-ID: <u63rr2zfg.fsf@agharta.de>

On Sun, 29 Jun 2008 19:13:19 -0700, Cyrus Harmon <ch-tbnl at bobobeach.com> wrote:

> It seems like it would be pretty straightforward to move the
> cl-webdav-level-2 stuff into it's own asdf system.

FWIW, I personally think that the level 2 support is a valid addition
and should eventually be part of cl-webdav itself.


From edi at agharta.de  Mon Jun 30 06:48:22 2008
From: edi at agharta.de (Edi Weitz)
Date: Mon, 30 Jun 2008 08:48:22 +0200
Subject: [hunchentoot-devel] cl-webdav-level-2.asd?
In-Reply-To: <B7D745D6-155C-472F-AB45-ADF36010AAC8@bobobeach.com> (Cyrus
	Harmon's message of "Sun, 29 Jun 2008 19:13:19 -0700")
References: <B7D745D6-155C-472F-AB45-ADF36010AAC8@bobobeach.com>
Message-ID: <u1w2f2zbd.fsf@agharta.de>

On Sun, 29 Jun 2008 19:13:19 -0700, Cyrus Harmon <ch-tbnl at bobobeach.com> wrote:

> The only tricky bits are the the handlers. How should we handle the
> bits that need to reach down into the existing propfind/get
> handlers?  We could just redefine these with the
> copy/pasted/modified code in the new asdf system, but that seems
> like a hacky OAOO violation that is likely to lead to subtle bugs
> down the road. Some sort of CLOS hackery with around methods? A list
> of functions to call for each handler?  Thoughts?

OOAO?  What does that mean?

Besides, if it is in a separate /system/, it doesn't have to be in a
separate /package/, right?


From ch-tbnl at bobobeach.com  Mon Jun 30 07:12:43 2008
From: ch-tbnl at bobobeach.com (Cyrus Harmon)
Date: Mon, 30 Jun 2008 00:12:43 -0700
Subject: [hunchentoot-devel] cl-webdav-level-2.asd?
In-Reply-To: <u63rr2zfg.fsf@agharta.de>
References: <B7D745D6-155C-472F-AB45-ADF36010AAC8@bobobeach.com>
	<u63rr2zfg.fsf@agharta.de>
Message-ID: <999D5B0D-2D03-49BF-9F55-39497D1F36A9@bobobeach.com>


Ok, that's good to hear. That brings up two points though:

1. should we leave my cxml-stp/xpath stuff in there are rewrite the  
xml bits to look more like the cxml code used elsewhere in cl-webdav?  
Obviously, I vote for leaving it as is, but that's mostly because I  
don't want to be bothered to rewrite this using straight cxml.

2. there may be other extensions to cl-webdav that don't belong in cl- 
webdav itself and the experience of trying to add locks may inform the  
API decisions regarding extensibility of cl-webdav. I'll answer the  
rest of this in the next message...

cyrus

On Jun 29, 2008, at 11:45 PM, Edi Weitz wrote:

> On Sun, 29 Jun 2008 19:13:19 -0700, Cyrus Harmon <ch-tbnl at bobobeach.com 
> > wrote:
>
>> It seems like it would be pretty straightforward to move the
>> cl-webdav-level-2 stuff into it's own asdf system.
>
> FWIW, I personally think that the level 2 support is a valid addition
> and should eventually be part of cl-webdav itself.
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel



From ch-tbnl at bobobeach.com  Mon Jun 30 07:15:21 2008
From: ch-tbnl at bobobeach.com (Cyrus Harmon)
Date: Mon, 30 Jun 2008 00:15:21 -0700
Subject: [hunchentoot-devel] cl-webdav-level-2.asd?
In-Reply-To: <u1w2f2zbd.fsf@agharta.de>
References: <B7D745D6-155C-472F-AB45-ADF36010AAC8@bobobeach.com>
	<u1w2f2zbd.fsf@agharta.de>
Message-ID: <636C1F0B-7D95-46FC-8CB9-4FB3E4FDB9EB@bobobeach.com>


On Jun 29, 2008, at 11:48 PM, Edi Weitz wrote:

> On Sun, 29 Jun 2008 19:13:19 -0700, Cyrus Harmon <ch-tbnl at bobobeach.com 
> > wrote:
>
>> The only tricky bits are the the handlers. How should we handle the
>> bits that need to reach down into the existing propfind/get
>> handlers?  We could just redefine these with the
>> copy/pasted/modified code in the new asdf system, but that seems
>> like a hacky OAOO violation that is likely to lead to subtle bugs
>> down the road. Some sort of CLOS hackery with around methods? A list
>> of functions to call for each handler?  Thoughts?
>
> OOAO?  What does that mean?

OOAO. Once and once only. Must be an sbcl-developerism. The idea is to  
avoid hacky duplicated code...

> Besides, if it is in a separate /system/, it doesn't have to be in a
> separate /package/, right?

yes, it can be in the same package. nevertheless, the issue of how to  
extend the existing handlers still arises. I have been thinking about  
this a little bit. Perhaps my thoughts will be clearer in the morning.



From neuss at math.uni-karlsruhe.de  Mon Jun 30 07:35:57 2008
From: neuss at math.uni-karlsruhe.de (Nicolas Neuss)
Date: Mon, 30 Jun 2008 09:35:57 +0200
Subject: [hunchentoot-devel] googlebot revisitation rate excessive?
In-Reply-To: <48681B63.40407@cunningham.net> (Jeff Cunningham's message of
	"Sun\, 29 Jun 2008 16\:31\:47 -0700")
References: <48681B63.40407@cunningham.net>
Message-ID: <87k5g7jrxe.fsf@ma-patru.mathematik.uni-karlsruhe.de>

Jeff Cunningham <jeffrey at cunningham.net> writes:

> Has anyone else noticed excessive visitation of pages served dynamically by
> Hunchentoot? On a couple of small sites virtually every page gets hit every
> five minutes by http://www.google.com/bot.html, regular as clockwork.
>
> Normally, I setup robots.txt to allow google to walk these sites but unless
> I can think of a way to tell them to back off to once a week or something
> I'm about to Disallow them. They're just little private sites and Google
> ends up being 99% of the traffic. It's silly.
>
> --Jeff

I do have the same problem: my log-File is 26 MB now, most of the stuff is
things like

...
[2008-06-30 09:15:26 [NOTICE]] No session for session identifier '29894:F42573291C09820112231789C68D301A' (User-Agent: 'Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)', IP: '127.0.0.1')
[2008-06-30 09:15:26] 127.0.0.1 (66.249.72.235) - "GET /vws/select-event?hunchentoot-session=29894%3AF42573291C09820112231789C68D301A HTTP/1.1" 200 1783 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
[2008-06-30 09:17:20 [NOTICE]] No session for session identifier '30162:09996937F640DAF47EE8B2855A18D04F' (User-Agent: 'Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)', IP: '127.0.0.1')
[2008-06-30 09:17:20] 127.0.0.1 (66.249.72.235) - "GET /vws/select-event?hunchentoot-session=30162%3A09996937F640DAF47EE8B2855A18D04F HTTP/1.1" 200 1783 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
[2008-06-30 09:19:15 [NOTICE]] No session for session identifier '30110:EE7334ECC6F70F8D5E6D1FB65CE62636' (User-Agent: 'Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)', IP: '127.0.0.1')
[2008-06-30 09:19:15] 127.0.0.1 (66.249.72.235) - "GET /vws/select-event?hunchentoot-session=30110%3AEE7334ECC6F70F8D5E6D1FB65CE62636 HTTP/1.1" 200 1783 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
[2008-06-30 09:20:46 [NOTICE]] No session for session identifier '27870:BFFDF4E7BA37F6508E41566C1E84BE70' (User-Agent: 'Mozilla/5.0 (Macintosh; U; Intel Mac OS X; de; rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14', IP: '127.0.0.1')
...

Unfortunately, the site is much in use administrating courses at our
institute (http://www.vorlesungsverwaltung.de).  So I don't want to
experiment at the moment.  Maybe we should contact Google and ask what
could be the reason.  I did not do it up to now, mostly because I am quite
short at time.

Yours, 
Nicolas