@@ -624,6 +626,16 @@
[Function]
+
raw-post-data &optional request => string
+
+
+If *SAVE-RAW-POST-DATA-P* is
+true and the request is a POST request, returns the raw body of
+the request, otherwise returns nil.
+
+
+
[Function]
parameter name &optional request => string
@@ -1490,6 +1502,16 @@
This should be a pathname denoting a directory where temporary files can be stored. It is used for file uploads.
+
[Special variable]
+
*save-raw-post-data-p*
+
+
+If this variable is set to a true value (the default is
+NIL), when a POST request is received, the raw body is
+saved, and may be retrieved with RAW-POST-DATA.
+
If you want to debug your TBNL applications it is recommend that you start Apache (i.e. the httpd binary) with the -X command-line option. Then set *DEBUG-MODE* to a true value and poke around in the listener. Good luck... :)
Only in tbnl-0.3.10/doc: index.html~
Only in tbnl-0.3.10: html.fasl
Only in tbnl-0.3.10: log.fasl
Only in tbnl-0.3.10: modlisp.fasl
Only in tbnl-0.3.10: packages.fasl
diff -ur tbnl-0.3.10-orig/packages.lisp tbnl-0.3.10/packages.lisp
--- tbnl-0.3.10-orig/packages.lisp 2005-01-24 06:50:46.000000000 -0500
+++ tbnl-0.3.10/packages.lisp 2005-02-21 11:31:57.000000000 -0500
@@ -46,6 +46,7 @@
#:*lisp-warnings-log-level*
#:*listener*
#:*log-lisp-backtraces-p*
+ #:*save-raw-post-data-p*
#:*log-lisp-errors-p*
#:*log-lisp-warnings-p*
#:*log-prefix*
@@ -130,6 +131,7 @@
#:get-parameter
#:get-parameters
#:handle-if-modified-since
+ #:raw-post-data
#:header-in
#:headers-in
#:header-out
Only in tbnl-0.3.10: packages.lisp~
Only in tbnl-0.3.10: reply.fasl
Only in tbnl-0.3.10: request.fasl
diff -ur tbnl-0.3.10-orig/request.lisp tbnl-0.3.10/request.lisp
--- tbnl-0.3.10-orig/request.lisp 2005-01-24 06:50:46.000000000 -0500
+++ tbnl-0.3.10/request.lisp 2005-02-21 11:57:38.000000000 -0500
@@ -50,7 +50,10 @@
(session :initform nil
:accessor session
:documentation "The session object associated with this
-request."))
+request.")
+ (raw-post-data :initform nil
+ :documentation "The raw string sent as the body of a
+POST request, populated only if *SAVE-RAW-POST-DATA-P* is non-nil."))
(:documentation "Objects of this class hold all the information
about an incoming request. They are created automatically by TBNL and
can be accessed by the corresponding handler."))
@@ -114,6 +117,8 @@
(let ((content (make-string (parse-integer content-length
:junk-allowed t))))
(read-sequence content content-stream)
+ (when *save-raw-post-data-p*
+ (setf (slot-value request 'raw-post-data) content))
content)))))
((starts-with-p content-type "multipart/form-data;" :test #'char-equal)
(handler-case
@@ -309,3 +314,6 @@
(setf (return-code) +http-not-modified+)
(throw 'tbnl-handler-done nil))
(values)))
+
+(defun raw-post-data (&optional (request *request*))
+ (slot-value request 'raw-post-data))
Only in tbnl-0.3.10: request.lisp.orig
Only in tbnl-0.3.10: request.lisp~
Only in tbnl-0.3.10: rfc2388.fasl
Only in tbnl-0.3.10: session.fasl
Only in tbnl-0.3.10: specials.fasl
diff -ur tbnl-0.3.10-orig/specials.lisp tbnl-0.3.10/specials.lisp
--- tbnl-0.3.10-orig/specials.lisp 2005-01-24 06:50:46.000000000 -0500
+++ tbnl-0.3.10/specials.lisp 2005-02-21 11:26:27.000000000 -0500
@@ -182,6 +182,10 @@
occurs. Will only have effect of *LOG-LISP-ERRORS-P* or
*LOG-LISP-BACKTRACES* are also true.")
+(defvar *save-raw-post-data-p* nil
+ "Whether the body of a POST request is made available through
+RAW-POST-DATA.")
+
(defvar-unbound *command*
"The current request as read from Apache/mod_lisp, converted into an
alist.")
Only in tbnl-0.3.10: specials.lisp~
Only in tbnl-0.3.10: util.fasl
From edi at agharta.de Mon Feb 21 21:29:02 2005
From: edi at agharta.de (Edi Weitz)
Date: Mon, 21 Feb 2005 22:29:02 +0100
Subject: [tbnl-devel] New version 0.3.11
Message-ID:
Changelog:
Version 0.3.11
2005-02-21
Added ability to access raw post data (suggested and coded by Zach Beane)
Download:
Cheers,
Edi.
From edi at agharta.de Fri Feb 25 20:33:56 2005
From: edi at agharta.de (Edi Weitz)
Date: Fri, 25 Feb 2005 21:33:56 +0100
Subject: [tbnl-devel] Re: TBNL Example
In-Reply-To: <421F1226.7000703@open.ac.uk> (Lukas Trejtnar's message of
"Fri, 25 Feb 2005 11:55:18 +0000")
References: <421F1226.7000703@open.ac.uk>
Message-ID:
Hi Lukas!
Please use the mailing list for further questions and comments.
Thanks.
On Fri, 25 Feb 2005 11:55:18 +0000, Lukas Trejtnar wrote:
> I have been using the mod_lisp module for a couple of years where I
> written a Lisp counterpart myself. I didn't implement a
> session/cookie management and because of that would like to start
> using your TBNL library. It looks like a great piece of work.
Thanks... :)
> I was reading through a documentation of TBNL and not sure about
> testing session expiration. My scenario would be a login page where
> a user would authorise and a new session would be created, then a
> user would browse pages and the session would be every time checked
> if it didn't expire. If it did, a user would be redirected to the
> login page. It's a standard scenario, I guess. Here comes my
> question.
>
> How do I hook up 'session expires' to the authorisation? After
> reading the documentation, I assume, that I would modify a value of
> *session-removal-hook* to redirection function. Is it how you
> designed it? Do you have any practical examples?
I'm not sure I fully understand your question, or maybe we're talking
about different things.
If you're using TBNL's session facility you don't have to keep track
of session expiry yourself - TBNL will do that for you. If you have
the same idea about session expiry that TBNL has, that is. Each
session object has a slot which holds the number of seconds this
session is valid without user interaction - see the docs for
SESSION-MAX-TIME.[1] If the user is idle longer than this period then
the session will be automatically invalidated. This doesn't necessary
mean that the session object is garbage-collected at this point but it
/does/ mean that you can't access the session object anymore,
i.e. TBNL will behave as if there had never been a session object.
In other words: Usually you shouldn't have to care about
*SESSION-REMOVAL-HOOK*, it's a finalizer kind of thing that's rarely
useful.
Now, sessions aren't necessarily related to authorization but they can
be used for it. One approach that I've been using is the following:
After a successful login the server stores some kind of object in the
session which "proofs" that the user is authorized, like this:
(setf (session-value 'user) (make-foo-object))
Then I can wrap all pages requiring authorization into a macro that
looks like this (untested):
(defmacro with-authorization (&body body)
`(cond ((is-foo-object (session-value 'user))
, at body)
(t (redirect "/login-page.html"))))
Does that answer your question?
Cheers,
Edi.
PS: I'll be away for two days so I probably won't answer before
monday.
[1] Just noticed that the default value (30 minutes) isn't documented
and *SESSION-MAX-TIME* isn't exported. This'll be fixed in a
future release.
From stesch at no-spoon.de Fri Feb 25 21:35:18 2005
From: stesch at no-spoon.de (Stefan Scholl)
Date: Fri, 25 Feb 2005 22:35:18 +0100
Subject: [tbnl-devel] Re: TBNL Example
In-Reply-To:
References: <421F1226.7000703@open.ac.uk>
Message-ID: <20050225213518.GL29337@parsec.no-spoon.de>
On 2005-02-25 21:33:56, Edi Weitz wrote:
> SESSION-MAX-TIME.[1] If the user is idle longer than this period then
> the session will be automatically invalidated. This doesn't necessary
> mean that the session object is garbage-collected at this point but it
> /does/ mean that you can't access the session object anymore,
> i.e. TBNL will behave as if there had never been a session object.
But I hope the session will be removed at some time, even when
nobody tries to access an expired session?
From edi at agharta.de Fri Feb 25 21:51:17 2005
From: edi at agharta.de (Edi Weitz)
Date: Fri, 25 Feb 2005 22:51:17 +0100
Subject: [tbnl-devel] Re: TBNL Example
In-Reply-To: <20050225213518.GL29337@parsec.no-spoon.de> (Stefan Scholl's
message of "Fri, 25 Feb 2005 22:35:18 +0100")
References: <421F1226.7000703@open.ac.uk>
<20050225213518.GL29337@parsec.no-spoon.de>
Message-ID:
On Fri, 25 Feb 2005 22:35:18 +0100, Stefan Scholl wrote:
> But I hope the session will be removed at some time, even when
> nobody tries to access an expired session?
Yes, see the code for SESSION-GC. It will be removed at some time
unless nobody tries to access any session at all, whether expired or
not.
To make this more clear:
1. Whenever you try to access an expired session it will be
automatically removed and thus your Lisp is free to garbage-collect
it now.
2. Whenever any session whatsoever is accessed a global counter is
increased and at certain intervals (there's a special variable for
that but I don't think it's exported) all sessions which are
expired will be removed even if their users haven't accesses them.
This implies that sessions might stay in the Lisp image for a long
time (although expired) /if/ there's no traffic /or/ if there's only
traffic that doesn't use sessions.
The alternative would be a separate thread which checks for expired
session independently of server traffic. I think that's overly
complex, though, and the benefit of the current solution is that it
kind of automatically adapts to the server load.
Cheers,
Edi.
From xach at xach.com Fri Feb 25 22:01:01 2005
From: xach at xach.com (Zach Beane)
Date: Fri, 25 Feb 2005 17:01:01 -0500
Subject: [tbnl-devel] Re: TBNL Example
In-Reply-To:
References: <421F1226.7000703@open.ac.uk>
<20050225213518.GL29337@parsec.no-spoon.de>
Message-ID: <20050225220100.GG11816@xach.com>
On Fri, Feb 25, 2005 at 10:51:17PM +0100, Edi Weitz wrote:
> The alternative would be a separate thread which checks for expired
> session independently of server traffic. I think that's overly
> complex, though, and the benefit of the current solution is that it
> kind of automatically adapts to the server load.
An option I've used in the past and intend to use with TBNL in the
future is to have a set of URLs with access restrictions and whose
handlers perform required periodic tasks. Then you could do something
like this from cron:
30 * * * * wget http://my.site.com/secret/hourly-stuff
(This sort of thing is not needed for sessions for the reasons you
provide, but I thought I'd bring up the possibility of a non-thread
solution for tasks that need to be done periodically.)
Zach
From hutch at recursive.ca Fri Feb 25 21:00:44 2005
From: hutch at recursive.ca (Bob Hutchison)
Date: Fri, 25 Feb 2005 16:00:44 -0500
Subject: [tbnl-devel] Weird problem with cookies and startup
Message-ID: <0a1167846989690c928c841f43f22751@recursive.ca>
Hi,
I've been using TBNL for a few weeks and am encountering some strange
behaviour when sessions time out. Specifically, once a session times
out I start getting multiple cookies written to the browser -- as the
user navigates around the site the cookie, and so the session, changes.
I am wondering if this is a known problem. If so, maybe some advice.
Otherwise, I'll try to isolate the problem better so I can provide a
more precise description of what is happening.
There is another problem for which I have no explanation: when the lisp
system is first started up it takes several attempts to load the page
before the page is loaded (it isn't getting as far as the lisp program
I think). Same thing: if this is familiar, maybe some advice...
otherwise I'll try to describe the problem better.
I'm using Lispworks 4.4 professional on OS/X (10.3.8) using what ever
the current versions of Apache 1.x (for OS/X) and mod_lisp.
Other that that, TBNL works beautifully. Very nice.
Cheers,
Bob
----
Bob Hutchison -- blogs at
Recursive Design Inc. --
From edi at agharta.de Fri Feb 25 22:17:27 2005
From: edi at agharta.de (Edi Weitz)
Date: Fri, 25 Feb 2005 23:17:27 +0100
Subject: [tbnl-devel] Weird problem with cookies and startup
In-Reply-To: <0a1167846989690c928c841f43f22751@recursive.ca> (Bob
Hutchison's message of "Fri, 25 Feb 2005 16:00:44 -0500")
References: <0a1167846989690c928c841f43f22751@recursive.ca>
Message-ID:
Hi Bob!
On Fri, 25 Feb 2005 16:00:44 -0500, Bob Hutchison wrote:
> I've been using TBNL for a few weeks and am encountering some
> strange behaviour when sessions time out. Specifically, once a
> session times out I start getting multiple cookies written to the
> browser -- as the user navigates around the site the cookie, and so
> the session, changes.
>
> I am wondering if this is a known problem. If so, maybe some
> advice. Otherwise, I'll try to isolate the problem better so I can
> provide a more precise description of what is happening.
I haven't seen that yet. If you could provide a reproducible test
case that'd be very nice.
> There is another problem for which I have no explanation: when the
> lisp system is first started up it takes several attempts to load
> the page before the page is loaded (it isn't getting as far as the
> lisp program I think). Same thing: if this is familiar, maybe some
> advice... otherwise I'll try to describe the problem better.
Had you used TBNL and/or mod_lisp before and then restarted the Lisp?
You might be fighting with Apache children trying to use now-dead
socket connections to the old Lisp image.
If that's the case restarting Apache is your best solution, `apachectl
graceful' should suffice.
> I'm using Lispworks 4.4 professional on OS/X (10.3.8) using what
> ever the current versions of Apache 1.x (for OS/X) and mod_lisp.
I don't use Macs so I hope this is not a Mac-specific problem that I
can't debug.
Cheers,
Edi.
From hutch at recursive.ca Fri Feb 25 22:30:54 2005
From: hutch at recursive.ca (Bob Hutchison)
Date: Fri, 25 Feb 2005 17:30:54 -0500
Subject: [tbnl-devel] Weird problem with cookies and startup
In-Reply-To:
References: <0a1167846989690c928c841f43f22751@recursive.ca>
Message-ID: <5616d00158194f8cac9232cf72b8c50d@recursive.ca>
On Feb 25, 2005, at 5:17 PM, Edi Weitz wrote:
> Hi Bob!
>
> On Fri, 25 Feb 2005 16:00:44 -0500, Bob Hutchison
> wrote:
>
>> I've been using TBNL for a few weeks and am encountering some
>> strange behaviour when sessions time out. Specifically, once a
>> session times out I start getting multiple cookies written to the
>> browser -- as the user navigates around the site the cookie, and so
>> the session, changes.
>>
>> I am wondering if this is a known problem. If so, maybe some
>> advice. Otherwise, I'll try to isolate the problem better so I can
>> provide a more precise description of what is happening.
>
> I haven't seen that yet. If you could provide a reproducible test
> case that'd be very nice.
OK, I should be able to get something together, though it might take a
couple of days.
>
>> There is another problem for which I have no explanation: when the
>> lisp system is first started up it takes several attempts to load
>> the page before the page is loaded (it isn't getting as far as the
>> lisp program I think). Same thing: if this is familiar, maybe some
>> advice... otherwise I'll try to describe the problem better.
>
> Had you used TBNL and/or mod_lisp before and then restarted the Lisp?
> You might be fighting with Apache children trying to use now-dead
> socket connections to the old Lisp image.
>
> If that's the case restarting Apache is your best solution, `apachectl
> graceful' should suffice.
There's an idea... I wish I had thought of it. I'll give that a shot.
I've got a feeling that somehow these two problems are related. I'll
try the restart and see if that fixes both problems -- if nothing else,
it'll eliminate some odd stuff.
>
>> I'm using Lispworks 4.4 professional on OS/X (10.3.8) using what
>> ever the current versions of Apache 1.x (for OS/X) and mod_lisp.
>
> I don't use Macs so I hope this is not a Mac-specific problem that I
> can't debug.
So do I :-)
Thanks,
Bob
>
> Cheers,
> Edi.
>
>
----
Bob Hutchison -- blogs at
Recursive Design Inc. --
From hutch at recursive.ca Sun Feb 27 14:00:38 2005
From: hutch at recursive.ca (Bob Hutchison)
Date: Sun, 27 Feb 2005 09:00:38 -0500
Subject: [tbnl-devel] Weird problem with cookies and startup
In-Reply-To: <0a1167846989690c928c841f43f22751@recursive.ca>
References: <0a1167846989690c928c841f43f22751@recursive.ca>
Message-ID: <0224d6459e28da2a8ff023d8939c2dfb@recursive.ca>
On Feb 25, 2005, at 4:00 PM, Bob Hutchison wrote:
> Hi,
>
> I've been using TBNL for a few weeks and am encountering some strange
> behaviour when sessions time out. Specifically, once a session times
> out I start getting multiple cookies written to the browser -- as the
> user navigates around the site the cookie, and so the session,
> changes.
>
> I am wondering if this is a known problem. If so, maybe some advice.
> Otherwise, I'll try to isolate the problem better so I can provide a
> more precise description of what is happening.
The restart does not fix this problem, but it is a lot clearer what is
going on. I still have not isolated the problem, I'll try to do that
today (if I don't manage it today other things will start interfering
and it'll take a bit longer)
This happens with both safari and firefox (I haven't tried any other
browsers), though the behaviour is a bit different. In the case of
Safari I get a cookie for each page I visited in the previous 'session'
plus one new cookie. In the case of firefox, I get two cookies: the old
one and the new one, and there is some sort of confusion between the
two. Firefox is a simpler situation so I'll try to isolate the problem
using it.
>
> There is another problem for which I have no explanation: when the
> lisp system is first started up it takes several attempts to load the
> page before the page is loaded (it isn't getting as far as the lisp
> program I think). Same thing: if this is familiar, maybe some
> advice... otherwise I'll try to describe the problem better.
The restart of Apache fixes this as far as I can tell. Thanks for the
suggestion.
>
> I'm using Lispworks 4.4 professional on OS/X (10.3.8) using what ever
> the current versions of Apache 1.x (for OS/X) and mod_lisp.
>
> Other that that, TBNL works beautifully. Very nice.
>
> Cheers,
> Bob
> ----
> Bob Hutchison -- blogs at
> Recursive Design Inc. --
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>
>
----
Bob Hutchison -- blogs at
Recursive Design Inc. --
From hutch at recursive.ca Sun Feb 27 14:11:16 2005
From: hutch at recursive.ca (Bob Hutchison)
Date: Sun, 27 Feb 2005 09:11:16 -0500
Subject: [tbnl-devel] Weird problem with cookies and startup
In-Reply-To: <0224d6459e28da2a8ff023d8939c2dfb@recursive.ca>
References: <0a1167846989690c928c841f43f22751@recursive.ca>
<0224d6459e28da2a8ff023d8939c2dfb@recursive.ca>
Message-ID: <91adaa4605057bad72bb191c5c17c931@recursive.ca>
On Feb 27, 2005, at 9:00 AM, Bob Hutchison wrote:
> Firefox is a simpler situation so I'll try to isolate the problem
> using it.
>
I was wrong. Firefox and Safari behave identically.
----
Bob Hutchison -- blogs at
Recursive Design Inc. --
From edi at agharta.de Sun Feb 27 16:46:36 2005
From: edi at agharta.de (Edi Weitz)
Date: Sun, 27 Feb 2005 17:46:36 +0100
Subject: [tbnl-devel] Re: problems compiling TBNL 0.3.11 in SBCL 0.8.19
In-Reply-To: <9455991c37e6884a78a261706ef0bef7@yahoo.com> (John Wiseman's
message of "Fri, 25 Feb 2005 23:54:42 -0800")
References: <9455991c37e6884a78a261706ef0bef7@yahoo.com>
Message-ID:
Hi John!
[Cc to mailing list.]
On Fri, 25 Feb 2005 23:54:42 -0800, John Wiseman wrote:
> Hi, Edi. I just wanted to let you know that I had some trouble
> compiling TBNL 0.3.11 in SBCL 0.8.19:
>
> ; /usr/local/lib/sbcl/site/tbnl-0.3.11/test/test.fasl written
> ; compilation finished in 0:00:02
>
> debugger invoked on a SB-INT:STREAM-DECODING-ERROR in thread 1771:
> decoding error on stream
> # \"/usr/local/lib/sbcl/site/tbnl-0.3.11/test/fz.jpg\"" {48E6BF81}>
> (:EXTERNAL-FORMAT :UTF-8):
> the octet sequence (255 216 255 224) cannot be decoded.
>
> You can type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.
>
> restarts (invokable by number or by possibly-abbreviated name):
> 0: [ATTEMPT-RESYNC ] Attempt to resync the stream at a character
> boundary
> and continue.
> 1: [FORCE-END-OF-FILE] Force an end of file.
> 2: [RETRY ] Retry performing # {48002121}> on
> #.
> 3: [ACCEPT ] Continue, treating # {48002121}> on
> # as
> having
> been successful.
> 4: [RETRY ] Retry installation
> 5: [ABORT ] Reduce debugger level (leaving debugger,
> returning to
> toplevel).
> 6: [TOPLEVEL ] Restart at toplevel READ/EVAL/PRINT loop.
> (SB-INT:STREAM-DECODING-ERROR
> 2
> # \"/usr/local/lib/sbcl/site/tbnl-0.3.11/test/fz.jpg\"" {48E6BF81}>
> (255 216 255 224))[:EXTERNAL]
Looks like SBCL is expecting an UTF-8 encoded stream. But this is a
JPG file and should be read as a sequence of octets. I'm not familiar
with SBCL's new Unicode facilities, I guess you have to provide the
right external format when opening the stream.
TBNL on the SBCL/Mac combo won't work, though, because TBNL needs
threads.
Cheers,
Edi.