From edi at agharta.de  Mon Aug  2 09:05:23 2004
From: edi at agharta.de (Edi Weitz)
Date: Mon, 02 Aug 2004 11:05:23 +0200
Subject: [tbnl-devel] Multiple mod_lisps (Was: Socket leaks, again)
In-Reply-To: <87d62tp3ru.fsf@bird.agharta.de> (Edi Weitz's message of "Sun,
	18 Jul 2004 20:29:57 +0200")
References: <87d62tp3ru.fsf@bird.agharta.de>
Message-ID: <87acxd29m4.fsf@bird.agharta.de>

Hi!

The recent 2.35 patch unfortunately introduces the possibility for
another bug: If you've configured multiple mod_lisp instances in one
Apache then a socket which has served one Lisp image may be re-used
for a different Lisp image. This shouldn't happen, of course.

The attached patch tries to fix that. It stores the server ip address
and port together with the socket and only re-uses the socket if the
former values haven't changed.

Cheers,
Edi.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: mod_lisp_2_37.patch
Type: text/x-patch
Size: 2942 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20040802/09ca8eb2/attachment.bin>

From edi at agharta.de  Mon Aug  2 09:12:35 2004
From: edi at agharta.de (Edi Weitz)
Date: Mon, 02 Aug 2004 11:12:35 +0200
Subject: [tbnl-devel] One more... :)
Message-ID: <87658129a4.fsf@bird.agharta.de>

Attached is another little patch. I made this a different patch from
the previous one (2.37) because it might be a bit controversial.

I've added two new headers - "apache-baseversion" which corresponds to
the APACHE_BASEVERSION constant (something like "Apache/1.3.29") and
"modlisp-version" which corresponds to the mod_lisp version string in
mod_lisp.c. I think it'd be nice to have these so the Lisp side can
prepare better diagnostic messages.

One might argue that it's overhead to send these headers with every
request. I personally think that this is not an issue because mod_lisp
is already extremely fast and it doesn't really matter whether you
send another 20 or 30 bytes through the socket or not.

One might also argue that this is static information which should only
be sent once. I'd disagree because - as we all know - you can update
your Apache while your Lisp image keeps running. You can also update
mod_lisp while your Lisp image keeps running. In both cases your Lisp
application will have the new versions available immediately.

Cheers,
Edi.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: mod_lisp_2_38.patch
Type: text/x-patch
Size: 846 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20040802/60761e36/attachment.bin>

From stesch at no-spoon.de  Mon Aug  2 09:40:26 2004
From: stesch at no-spoon.de (Stefan Scholl)
Date: Mon, 2 Aug 2004 11:40:26 +0200
Subject: [tbnl-devel] One more... :)
In-Reply-To: <87658129a4.fsf@bird.agharta.de>
References: <87658129a4.fsf@bird.agharta.de>
Message-ID: <20040802094026.GB4076@parsec.no-spoon.de>

On 2004-08-02 11:12:35, Edi Weitz wrote:
> I've added two new headers - "apache-baseversion" which corresponds to
> the APACHE_BASEVERSION constant (something like "Apache/1.3.29") and
> "modlisp-version" which corresponds to the mod_lisp version string in
> mod_lisp.c. I think it'd be nice to have these so the Lisp side can
> prepare better diagnostic messages.

Then TBNL needs a version string, too. Or is there a way to get
to this with ASDF?


Regards,
Stefan





From edi at agharta.de  Mon Aug  2 10:04:20 2004
From: edi at agharta.de (Edi Weitz)
Date: Mon, 02 Aug 2004 12:04:20 +0200
Subject: [tbnl-devel] One more... :)
In-Reply-To: <20040802094026.GB4076@parsec.no-spoon.de> (Stefan Scholl's
	message of "Mon, 2 Aug 2004 11:40:26 +0200")
References: <87658129a4.fsf@bird.agharta.de>
	<20040802094026.GB4076@parsec.no-spoon.de>
Message-ID: <87acxdrh3v.fsf@bird.agharta.de>

On Mon, 2 Aug 2004 11:40:26 +0200, Stefan Scholl <stesch at no-spoon.de> wrote:

> Then TBNL needs a version string, too.

This is already in my local repository. But it wouldn't make sense to
release it until Marc accepts the 2.38 patch.

Edi.



From edi at agharta.de  Tue Aug  3 05:34:48 2004
From: edi at agharta.de (Edi Weitz)
Date: Tue, 03 Aug 2004 07:34:48 +0200
Subject: [tbnl-devel] Handling HTTP errors
In-Reply-To: <20040731001011.GH4076@parsec.no-spoon.de> (Stefan Scholl's
	message of "Sat, 31 Jul 2004 02:10:11 +0200")
References: <20040731001011.GH4076@parsec.no-spoon.de>
Message-ID: <87acxclr7r.fsf@bird.agharta.de>

On Sat, 31 Jul 2004 02:10:11 +0200, Stefan Scholl <stesch at no-spoon.de> wrote:

> Function send-output in modlisp.lisp handles the response for
> different return codes. E. g. there's a "The requested URL ~A was
> not found on this server." for the 404 (+http-not-found+).
>
> How about letting the user change this behavior?
>
> One could explain the error to the user. Maybe in another language.
>
> Or think of all the funny 404 games. Remember the SGI babies?

Like so? <http://weitz.de/not-there>

:)

> There could be different approaches:
>
> * Simple hash
>   A hash with error code as key and handler as value.
>
>   + Easy to implement
>   + Can handle all errors (thrown by handlers _and_ when no
>     dispatcher is found)
>   - Not very flexible. Just checks for the code and not for
>     any request data.
>
> * Error dispatcher
>   Like the normal dispatcher, but checking for the right error
>   output handler.
>
>   + Can handle all errors (thrown by handlers _and_ when no
>     dispatcher is found)
>   + Flexible. Can check the code _and_ request data.
>   - A bit big. The same effort like handling normal requests.
>
> * Handler outputs itself and signals that
>   A handler wants to return a 404. It constructs the output
>   string and signals the fact that there's no need for TBNL to
>   build the HTML for the output.
>
>   + Easy to implement(? clean?)
>   + Flexible
>   - Can't handle all errors. (No handler found? Then the code
>     won't be executed.)

I agree that this would generally be a good idea. I'm not sure yet
which of the above-mentioned alternatives I like most or if there's
another one that would even be better.

Cheers,
Edi.



From edi at agharta.de  Tue Aug  3 05:41:53 2004
From: edi at agharta.de (Edi Weitz)
Date: Tue, 03 Aug 2004 07:41:53 +0200
Subject: [tbnl-devel] Re: [mod-lisp-devel] Multiple mod_lisps
In-Reply-To: <87acxd29m4.fsf@bird.agharta.de> (Edi Weitz's message of "Mon,
	02 Aug 2004 11:05:23 +0200")
References: <87d62tp3ru.fsf@bird.agharta.de> <87acxd29m4.fsf@bird.agharta.de>
Message-ID: <876580lqvy.fsf@bird.agharta.de>

On Mon, 02 Aug 2004 11:05:23 +0200, Edi Weitz <edi at agharta.de> wrote:

> @@ -431,11 +442,13 @@
>  #ifndef WIN32
>    if (LispSocket)
>      {
> -      if (UnsafeLispSocket)
> +      if (UnsafeLispSocket || strcmp(cfg->LispServerIP, LispServerIP) || cfg->LispServerPort != LispServerPort)
>          {
>            ap_pclosesocket(SocketPool, LispSocket);
>            LispSocket = 0;
>            UnsafeLispSocket = 0;
> +          LispServerIP[0] = 0;
> +          LispServerPort = 0;
>          }
>        else
>          return LispSocket;

As a micro-optimization one might want to replace the line above with

  +      if (UnsafeLispSocket || cfg->LispServerPort != LispServerPort || strcmp(cfg->LispServerIP, LispServerIP))

Comparing two longs should generally be faster than calling strcmp and
it's not unlikely that that the different Lisp images will be on the
same machine but use different ports.

Cheers,
Edi.



From stesch at no-spoon.de  Tue Aug  3 19:06:51 2004
From: stesch at no-spoon.de (Stefan Scholl)
Date: Tue, 3 Aug 2004 21:06:51 +0200
Subject: [tbnl-devel] Handling HTTP errors
In-Reply-To: <87acxclr7r.fsf@bird.agharta.de>
References: <20040731001011.GH4076@parsec.no-spoon.de>
	<87acxclr7r.fsf@bird.agharta.de>
Message-ID: <20040803190651.GX4076@parsec.no-spoon.de>

On 2004-08-03 07:34:48, Edi Weitz wrote:
> On Sat, 31 Jul 2004 02:10:11 +0200, Stefan Scholl <stesch at no-spoon.de> wrote:
> > There could be different approaches:
> >
> > * Simple hash
> >   A hash with error code as key and handler as value.
> >
> >   + Easy to implement
> >   + Can handle all errors (thrown by handlers _and_ when no
> >     dispatcher is found)
> >   - Not very flexible. Just checks for the code and not for
> >     any request data.
> >
> > * Error dispatcher
> >   Like the normal dispatcher, but checking for the right error
> >   output handler.
> >
> >   + Can handle all errors (thrown by handlers _and_ when no
> >     dispatcher is found)
> >   + Flexible. Can check the code _and_ request data.
> >   - A bit big. The same effort like handling normal requests.
> >
> > * Handler outputs itself and signals that
> >   A handler wants to return a 404. It constructs the output
> >   string and signals the fact that there's no need for TBNL to
> >   build the HTML for the output.
> >
> >   + Easy to implement(? clean?)
> >   + Flexible
> >   - Can't handle all errors. (No handler found? Then the code
> >     won't be executed.)

* Generic function
  Make a specialized method if you want to catch a certain
  error. 
  E. g. (defmethod error-handler ((code (eql #.+http-not-found+)) ...

  + Easy to implement
  + Can handle all errors (thrown by handlers _and_ when no
    dispatcher is found)
  + Let CLOS to the "lookup" work
  + CLOS: You can add :before, :around, :after, ... methods
  - Not very flexible. Just checks for the code and not for any
    request data.


> I agree that this would generally be a good idea. I'm not sure yet
> which of the above-mentioned alternatives I like most or if there's
> another one that would even be better.

Do we need all the features (and more) of Apache's ErrorDocument?
<http://httpd.apache.org/docs/mod/core.html#errordocument>

A function can call the redirect itself.

If you don't need someting similar to the contexts (server
config, virtual host, directory, .htaccess) of ErrorDocument then
a hash table or generic function is enough.

The contexts can be simulated with error dispatcher which checks
the request, too.

But how often would someone need this together with mod_lisp? If
someone wants to emit different error messages for the same error
code but different request data (host, uri, ...) then he could
handle this himself.



Regards,
Stefan





From stesch at no-spoon.de  Fri Aug  6 12:45:02 2004
From: stesch at no-spoon.de (Stefan Scholl)
Date: Fri, 6 Aug 2004 14:45:02 +0200
Subject: [tbnl-devel] Tip: Checking for UTF-8 in submitted form
Message-ID: <20040806124502.GC4076@parsec.no-spoon.de>

http://paste.lisp.org/display/2141





From d95-bli at nada.kth.se  Tue Aug 10 12:27:33 2004
From: d95-bli at nada.kth.se (=?iso-8859-1?q?Bj=F6rn_Lindberg?=)
Date: Tue, 10 Aug 2004 12:27:33 -0000
Subject: [tbnl-devel] Authorized pages
Message-ID: <hcs1xifjhzj.fsf@my.nada.kth.se>

Hi all,

First I'd like to say that TBNL looks really nice, and replaces much
of what I have been trying to do lately on my own.

I have a question regarding authorization; The goal of having
authorization is to provide restricted access to a set of pages. The
example in test.lisp on gives access to one page, which is the one
generated by the authorization-page function itself.

How would I go about using authroization to restrict access to a set
of pages, perhaps even including static ones? Should I set it up so
that a prefix of the URIs of that set always leads to a handler which
calls authorization? In that case, how would such a handler look like?

Thanks,


Bj?rn



From edi at agharta.de  Tue Aug 10 13:21:41 2004
From: edi at agharta.de (Edi Weitz)
Date: Tue, 10 Aug 2004 15:21:41 +0200
Subject: [tbnl-devel] Authorized pages
In-Reply-To: <hcs1xifjhzj.fsf@my.nada.kth.se> =?iso-8859-1?q?=28Bj=F6rn?=
	Lindberg's message of "10 Aug 2004 14:27:28 +0200")
References: <hcs1xifjhzj.fsf@my.nada.kth.se>
Message-ID: <87ekmfnn6i.fsf@bird.agharta.de>

On 10 Aug 2004 14:27:28 +0200, d95-bli at nada.kth.se (Bj?rn Lindberg) wrote:

> First I'd like to say that TBNL looks really nice, and replaces much
> of what I have been trying to do lately on my own.

Thanks.

> I have a question regarding authorization; The goal of having
> authorization is to provide restricted access to a set of pages. The
> example in test.lisp on gives access to one page, which is the one
> generated by the authorization-page function itself.
>
> How would I go about using authroization to restrict access to a set
> of pages, perhaps even including static ones? Should I set it up so
> that a prefix of the URIs of that set always leads to a handler
> which calls authorization? In that case, how would such a handler
> look like?

TBNL currently doesn't have code to automate that. You can, of course,
use Apache's facilities and ignore TBNL. Or you might want to do
something like this (untested)

  (defmacro with-authorization ((authorizer) &body body)
    (with-unique-names (user password)
      `(multiple-value-bind (,user ,password)
          (authorization)
        (cond ((funcall ,authorizer ,user ,password)
               , at body)
              (t
               (require-authorization))))))

  (defun my-authorizer (user password)
    (and (string= user "foo")
         (string= password "bar")))

and then

  (defun page ()
    (with-authorization (#'my-authorizer)
      (with-html
        (:html     
          (:head (:title "Blabla"))
          (:body "More bla")))))

Another option would be to let the first dispatcher in the list of
dispatchers do the following:

  1. If URL doesn't need authorization just return NIL so the next
     dispatcher has its turn.

  2. If URL needs authorization and user is authorized also return
     NIL.

  3. Otherwise dispatch to a fixed handler which just calls
     REQUIRE-AUTHORIZATION.

Does that help?

Cheers,
Edi.



From stesch at no-spoon.de  Tue Aug 10 13:29:05 2004
From: stesch at no-spoon.de (Stefan Scholl)
Date: Tue, 10 Aug 2004 15:29:05 +0200
Subject: [tbnl-devel] Authorized pages
In-Reply-To: <hcs1xifjhzj.fsf@my.nada.kth.se>
References: <hcs1xifjhzj.fsf@my.nada.kth.se>
Message-ID: <20040810132905.GL10420@parsec.no-spoon.de>

On 2004-08-10 14:27:28, Bj?rn Lindberg wrote:
> How would I go about using authroization to restrict access to a set
> of pages, perhaps even including static ones? Should I set it up so
> that a prefix of the URIs of that set always leads to a handler which
> calls authorization? In that case, how would such a handler look like?


You could write a wrapper function for the handler. Or a function
which generates wrapper functions for the handler, according for
the specific authorization needs.

Your own dispatcher (or one generated with
CREATE-PREFIX-DISPATCHER or CREATE-REGEX-DISPATCHER) then just
calls the wrapper. The wrapper handles the authorization and
calls either REQUIRE-AUTHORIZATION or your original handler.

Something like this:

  (create-prefix-dispatcher "/dealer/"
                            (generate-auth-wrapper
                              "dealer"
                              #'dealer-handler))


If you really need to protect static files, too, then I'd suggest
to write your own version of CREATE-STATIC-FILE-DISPATCHER-AND-HANDLER.
Code is in html.lisp

 [...]
     (when (equal (script-name request) uri)
       ;; the handler
+      (generate-auth-wrapper
+        auth-group
         (lambda ()
 [...]



Regards,
Stefan





From d95-bli at nada.kth.se  Tue Aug 10 14:49:27 2004
From: d95-bli at nada.kth.se (=?iso-8859-1?q?Bj=F6rn_Lindberg?=)
Date: Tue, 10 Aug 2004 14:49:27 -0000
Subject: [tbnl-devel] Authorized pages
In-Reply-To: <87ekmfnn6i.fsf@bird.agharta.de>
References: <hcs1xifjhzj.fsf@my.nada.kth.se> <87ekmfnn6i.fsf@bird.agharta.de>
Message-ID: <hcspt5zhwuj.fsf@my.nada.kth.se>

Edi Weitz <edi at agharta.de> writes:

> > I have a question regarding authorization; The goal of having
> > authorization is to provide restricted access to a set of pages. The
> > example in test.lisp on gives access to one page, which is the one
> > generated by the authorization-page function itself.
> >
> > How would I go about using authroization to restrict access to a set
> > of pages, perhaps even including static ones? Should I set it up so
> > that a prefix of the URIs of that set always leads to a handler
> > which calls authorization? In that case, how would such a handler
> > look like?
> 
> TBNL currently doesn't have code to automate that. You can, of course,
> use Apache's facilities and ignore TBNL. Or you might want to do
> something like this (untested)
> 
>   (defmacro with-authorization ((authorizer) &body body)
>     (with-unique-names (user password)
>       `(multiple-value-bind (,user ,password)
>           (authorization)
>         (cond ((funcall ,authorizer ,user ,password)
>                , at body)
>               (t
>                (require-authorization))))))
> 
>   (defun my-authorizer (user password)
>     (and (string= user "foo")
>          (string= password "bar")))
> 
> and then
> 
>   (defun page ()
>     (with-authorization (#'my-authorizer)
>       (with-html
>         (:html     
>           (:head (:title "Blabla"))
>           (:body "More bla")))))
> 
> Another option would be to let the first dispatcher in the list of
> dispatchers do the following:
> 
>   1. If URL doesn't need authorization just return NIL so the next
>      dispatcher has its turn.
> 
>   2. If URL needs authorization and user is authorized also return
>      NIL.
> 
>   3. Otherwise dispatch to a fixed handler which just calls
>      REQUIRE-AUTHORIZATION.
> 
> Does that help?

Yes, I believe so. I think my insufficient understanding of the
underlying HTTP mechanism led me to believe it was more complicated
than it apparently is.

Am I correct now to believe that it is in reality Apache which takes
care of the authorization, so that once a user gave a proper username
and password, he will be authorized for the rest of his session? So
all that needs to be done is for each and every handler of access
restricted pages to call tbnl:authorization and check for valid
username and passwords?

If the above is correct, then any misconceptions has been cleared up
on my part. Both you and Stefan gave me some good suggestions for what
to try. I suspect that the with-authorization macro is the simplest
solution if the number of access restricted pages are small, which
they are in my case, so maybe I will go with that. I'll experiment
with it tonight.


Bj?rn



From edi at agharta.de  Tue Aug 10 14:59:14 2004
From: edi at agharta.de (Edi Weitz)
Date: Tue, 10 Aug 2004 16:59:14 +0200
Subject: [tbnl-devel] Authorized pages
In-Reply-To: <hcspt5zhwuj.fsf@my.nada.kth.se> =?iso-8859-1?q?=28Bj=F6rn?=
	Lindberg's message of "10 Aug 2004 16:49:24 +0200")
References: <hcs1xifjhzj.fsf@my.nada.kth.se> <87ekmfnn6i.fsf@bird.agharta.de>
	<hcspt5zhwuj.fsf@my.nada.kth.se>
Message-ID: <87r7qfkpj1.fsf@bird.agharta.de>

On 10 Aug 2004 16:49:24 +0200, d95-bli at nada.kth.se (Bj?rn Lindberg) wrote:

> Am I correct now to believe that it is in reality Apache which takes
> care of the authorization, so that once a user gave a proper
> username and password, he will be authorized for the rest of his
> session?

No. The HTTP protocol has no concept of a "session" at all - each
request/reply pair is treated in isolation.

Basic authentication works like this:

0. Client sends a request.

1. The server somehow checks whether the client (the browser) has sent
   the proper username and password. (These are encoded in a header
   the client sends.)

   How this is checked can be implemented in different ways. You can
   ask Apache to handle this but in the examples just given (macro,
   dispatcher, and so on) Apache was not involved but rather TBNL did
   the checking.

2. If username and password are OK the server sends the requested
   contents.

3. If they're not OK the server sends back a 401 (Unauthorized) return
   code. It will also usually send back a "WWW-Authenticate" header
   which reveals a "Realm" to the client. This action /might/ result
   in a box popping up in your browser asking you to enter the
   credentials.

This process can be repeated as often as needed. Note that no
knowledge of what happended in the past (no "session") is required for
this.

> So all that needs to be done is for each and every handler of access
> restricted pages to call tbnl:authorization and check for valid
> username and passwords?

Yes.



From d95-bli at nada.kth.se  Tue Aug 10 15:29:31 2004
From: d95-bli at nada.kth.se (=?iso-8859-1?q?Bj=F6rn_Lindberg?=)
Date: Tue, 10 Aug 2004 15:29:31 -0000
Subject: [tbnl-devel] Authorized pages
In-Reply-To: <87r7qfkpj1.fsf@bird.agharta.de>
References: <hcs1xifjhzj.fsf@my.nada.kth.se> <87ekmfnn6i.fsf@bird.agharta.de>
	<hcspt5zhwuj.fsf@my.nada.kth.se> <87r7qfkpj1.fsf@bird.agharta.de>
Message-ID: <hcsllgnhuzr.fsf@my.nada.kth.se>

Edi Weitz <edi at agharta.de> writes:

> On 10 Aug 2004 16:49:24 +0200, d95-bli at nada.kth.se (Bj?rn Lindberg) wrote:
> 
> > Am I correct now to believe that it is in reality Apache which takes
> > care of the authorization, so that once a user gave a proper
> > username and password, he will be authorized for the rest of his
> > session?
> 
> No. The HTTP protocol has no concept of a "session" at all - each
> request/reply pair is treated in isolation.
> 
> Basic authentication works like this:
> 
> 0. Client sends a request.
> 
> 1. The server somehow checks whether the client (the browser) has sent
>    the proper username and password. (These are encoded in a header
>    the client sends.)
> 
>    How this is checked can be implemented in different ways. You can
>    ask Apache to handle this but in the examples just given (macro,
>    dispatcher, and so on) Apache was not involved but rather TBNL did
>    the checking.
> 
> 2. If username and password are OK the server sends the requested
>    contents.
> 
> 3. If they're not OK the server sends back a 401 (Unauthorized) return
>    code. It will also usually send back a "WWW-Authenticate" header
>    which reveals a "Realm" to the client. This action /might/ result
>    in a box popping up in your browser asking you to enter the
>    credentials.
> 
> This process can be repeated as often as needed. Note that no
> knowledge of what happended in the past (no "session") is required for
> this.

I see. the reason I thought it was handled by HTTP was because, as you
imply, the window requesting username and password usually only pops
up once. If there nowhere in the chain was any caching of the two, or
'state', then the access window would pop up for each and every access
restricted page.

Now you've led me to believe that it is actually the client's browser
that is storing the authentification information and resending it upon
request from the server. Is this right? (Sorry for bothering you with
this elementia.)

> > So all that needs to be done is for each and every handler of access
> > restricted pages to call tbnl:authorization and check for valid
> > username and passwords?
> 
> Yes.

Well, that is comforting at least. :-)


Bj?rn



From edi at agharta.de  Tue Aug 10 15:51:04 2004
From: edi at agharta.de (Edi Weitz)
Date: Tue, 10 Aug 2004 17:51:04 +0200
Subject: [tbnl-devel] Authorized pages
In-Reply-To: <hcsllgnhuzr.fsf@my.nada.kth.se> =?iso-8859-1?q?=28Bj=F6rn?=
	Lindberg's message of "10 Aug 2004 17:29:28 +0200")
References: <hcs1xifjhzj.fsf@my.nada.kth.se> <87ekmfnn6i.fsf@bird.agharta.de>
	<hcspt5zhwuj.fsf@my.nada.kth.se> <87r7qfkpj1.fsf@bird.agharta.de>
	<hcsllgnhuzr.fsf@my.nada.kth.se>
Message-ID: <87acx3kn4n.fsf@bird.agharta.de>

On 10 Aug 2004 17:29:28 +0200, d95-bli at nada.kth.se (Bj?rn Lindberg) wrote:

> I see. the reason I thought it was handled by HTTP was because, as
> you imply, the window requesting username and password usually only
> pops up once. If there nowhere in the chain was any caching of the
> two, or 'state', then the access window would pop up for each and
> every access restricted page.
>
> Now you've led me to believe that it is actually the client's
> browser that is storing the authentification information and
> resending it upon request from the server. Is this right? (Sorry for
> bothering you with this elementia.)

Yes, it's the browser which (re-)sends the credentials
automatically. Actually, it should try each request without
credentials first because the server doesn't provide any information
as to which other pages need authorization (and even if the same page
will still require authorization tomorrow or in ten seconds).

However, that would involve two requests per each page and the browser
would get very many 401 replies. Therefore, all current browser will
volunteer to send credentials based on certain heuristics (like if
it's the same server and the same directory or somesuch).

Cheers,
Edi.



From edi at agharta.de  Wed Aug 11 05:46:10 2004
From: edi at agharta.de (Edi Weitz)
Date: Wed, 11 Aug 2004 07:46:10 +0200
Subject: [tbnl-devel] New version 0.2.9
Message-ID: <871xiei5wd.fsf@bird.agharta.de>

Hi!

Just released a new version. Get it from:

  <http://weitz.de/files/tbnl.tgz>.

Here's the Changelog entry:

  Version 0.2.9
  2004-08-11
  Consistent usage of RFC-1123-DATE (provided by Stefan Scholl)
  Added all missing http headers from RFC 2616 (provided by Stefan Scholl)
  Added support for mod_lisp version strings (see <http://common-lisp.net/pipermail/mod-lisp-devel/2004-August/000019.html>)
  Don't always add session IDs when redirecting

Edi.



From edi at agharta.de  Thu Aug 19 18:14:19 2004
From: edi at agharta.de (Edi Weitz)
Date: Thu, 19 Aug 2004 20:14:19 +0200
Subject: [tbnl-devel] Re: Suggestion for a  possible TBNL improvement
In-Reply-To: <4124B2E6.8060804@paoloastori.com> (Massimiliano Campagnoli's
	message of "Thu, 19 Aug 2004 16:02:14 +0200")
References: <4124B2E6.8060804@paoloastori.com>
Message-ID: <87fz6jq9l0.fsf@bird.agharta.de>

Hi!

On Thu, 19 Aug 2004 16:02:14 +0200, Massimiliano Campagnoli <maxi at paoloastori.com> wrote:

> first of all thank you for providing to the lisp community such a
> useful utility.
>
> I would like to propose the following improvement.
>
> create-prefix-dispatcher prefix handler => dispatch-fn
>
> is a useful function for returning a dispatcher-fn that will return
> an handler whenever the part of the requested URI starts with prefix
>
> But what about form data ?  Would'nt be nice to have something like
>
> create-input-form-dispatcher parameter value handler => dispatch-fn
>
> for returning a dispatch-fn that will return an handler whenever a
> given post/get-paramter has the value value ?
>
> This function would be particularly useful in processing form data
> such as submit button etc.

I cannot see how this would be immediately useful - I at least don't
write web applications that dispatch to different handlers based on
the supplied parameters. However, it shouldn't be hard to write this
function yourself. Other opinions?

Please use the mailing list (see Cc) for further discussion of this
topic. Thanks.

Cheers,
Edi.



From maxi at paoloastori.com  Fri Aug 20 09:45:54 2004
From: maxi at paoloastori.com (Massimiliano Campagnoli)
Date: Fri, 20 Aug 2004 11:45:54 +0200
Subject: [tbnl-devel] Re: Suggestion for a possible TBNL improvement
Message-ID: <4125C852.8060406@paoloastori.com>

Well, suppose you have a purchase order entry form where you have to 
add/delete/save different line items.
Tipically you'll have an ADD/DELETE/SAVE submit buttons with the same 
name (e.g. FORM-BUTTON) but with three different values (e.g. ADD, 
DELETE, SAVE) to be handled by three different LISP functions.

Something like :

(create-input-form-dispatcher FORM-BUTTON ADD ADD-ITEM-HANDLER)
(create-input-form-dispatcher FORM-BUTTON DELETE DELETE-ITEM-HANDLER)
(create-input-form-dispatcher FORM-BUTTON SAVE SAVE-ITEM-HANDLER)

would return three dispatchers for these three events.

-- 
ING. MASSIMILIANO CAMPAGNOLI

PAOLO ASTORI SRL
VIA MIRABELLA, 9
28013 - GATTICO 
ITALY





From stesch at no-spoon.de  Fri Aug 20 10:11:07 2004
From: stesch at no-spoon.de (Stefan Scholl)
Date: Fri, 20 Aug 2004 12:11:07 +0200
Subject: [tbnl-devel] Re: Suggestion for a possible TBNL improvement
In-Reply-To: <4125C852.8060406@paoloastori.com>
References: <4125C852.8060406@paoloastori.com>
Message-ID: <20040820101107.GT28866@parsec.no-spoon.de>

I let the handler function dispatch to the specialized functions
for processing a form.

Most forms are more complex than just "if value is set run
function ...". E. g. submit/preview can be set even when all the
other form fields are not (not filled, or a crack attempt without
browser). I have a form which runs the edit function when a
preview is wanted and all the fields are empty.


Regards,
Stefan




From maxi at paoloastori.com  Mon Aug 23 12:38:10 2004
From: maxi at paoloastori.com (Massimiliano Campagnoli)
Date: Mon, 23 Aug 2004 14:38:10 +0200
Subject: [tbnl-devel] Help needed in handler function with (sleep seconds)
Message-ID: <4129E532.3040706@paoloastori.com>

I have defined this function as an handler:

(defun my-handler ()
  (sleep 2)
  (no-cache)
  (with-html (:html (:body (:h2 " Wait Test Perfomed") ) ) )
)

and added (create-prefix-dispatcher "/tbnl/test/myhandler.html"  
my-handler) as a list
into *dispatch-table*.

When I access /http://linuxbox/tbnl/test/myhandler/ I cannot see 
anything but
if I comment out (sleep 2) from my-handler everything works fine and the 
message
Wait Test Perfomed is displayed on the browser.

Can you please explain me what is going on ?

My purpose what to test TBNL under long-lasting function handler, like 
handler accesing database via CLSQL.

Thanks,

-- 
ING. MASSIMILIANO CAMPAGNOLI

PAOLO ASTORI SRL
VIA MIRABELLA, 9
28013 - GATTICO 
ITALY


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

From edi at agharta.de  Mon Aug 23 14:07:08 2004
From: edi at agharta.de (Edi Weitz)
Date: Mon, 23 Aug 2004 16:07:08 +0200
Subject: [tbnl-devel] Help needed in handler function with (sleep seconds)
In-Reply-To: <4129E532.3040706@paoloastori.com> (Massimiliano Campagnoli's
	message of "Mon, 23 Aug 2004 14:38:10 +0200")
References: <4129E532.3040706@paoloastori.com>
Message-ID: <87r7pyosmr.fsf@bird.agharta.de>

On Mon, 23 Aug 2004 14:38:10 +0200, Massimiliano Campagnoli <maxi at paoloastori.com> wrote:

> I have defined this function as an handler:
>
> (defun my-handler ()
>   (sleep 2)
>   (no-cache)
>   (with-html (:html (:body (:h2 " Wait Test Perfomed") ) ) )
> )

You should get rid of the extra spaces. It's ugly and non-standard.

> and added (create-prefix-dispatcher "/tbnl/test/myhandler.html"
> my-handler) as a list
> into *dispatch-table*.

How do you mean that, "added as a list?"

> When I access /http://linuxbox/tbnl/test/myhandler/

I suppose you mean http://linuxbox/tbnl/test/myhandler.html.

> I cannot see anything but if I comment out (sleep 2) from my-handler
> everything works fine and the message Wait Test Perfomed is
> displayed on the browser.
>
> Can you please explain me what is going on ?

I cannot reproduce your results. If I add your MY-HANDLER function to
the TBNL tests then it acts as expected, i.e. I see the page after
about two seconds. Can anyone else see this problem?

Which Lisp are you using? Do you see anything relevant in the Apache
log files?

Cheers,
Edi.



From maxi at paoloastori.com  Mon Aug 23 14:55:49 2004
From: maxi at paoloastori.com (Massimiliano Campagnoli)
Date: Mon, 23 Aug 2004 16:55:49 +0200
Subject: [tbnl-devel] Help needed in handler function with (sleep seconds)
Message-ID: <412A0575.9040305@paoloastori.com>

I am using:

CMUCL 19a
RedHat 9
apache 2.0.40
mod_lisp for apache 2

No errors is shown on Apache logs

May be I should try to move back to apache 1.3 with the latest mod_lisp 
release.

-- 
ING. MASSIMILIANO CAMPAGNOLI

PAOLO ASTORI SRL
VIA MIRABELLA, 9
28013 - GATTICO 
ITALY





From edi at agharta.de  Mon Aug 23 15:21:14 2004
From: edi at agharta.de (Edi Weitz)
Date: Mon, 23 Aug 2004 17:21:14 +0200
Subject: [tbnl-devel] Help needed in handler function with (sleep seconds)
In-Reply-To: <412A0575.9040305@paoloastori.com> (Massimiliano Campagnoli's
	message of "Mon, 23 Aug 2004 16:55:49 +0200")
References: <412A0575.9040305@paoloastori.com>
Message-ID: <87d61hkhhx.fsf@bird.agharta.de>

On Mon, 23 Aug 2004 16:55:49 +0200, Massimiliano Campagnoli <maxi at paoloastori.com> wrote:

> I am using:
>
> CMUCL 19a
> RedHat 9
> apache 2.0.40
> mod_lisp for apache 2

There are several versions as far as I know.

> No errors is shown on Apache logs

Does the page appear in the access log? Can you see something if you
trace ports 80 and 3000 with Ethereal?

> May be I should try to move back to apache 1.3 with the latest
> mod_lisp release.

As you will know from the docs TBNL doesn't officially support Apache
2. I've never used Apache 2 so I can't help you there - maybe someone
else can. Or you try with 1.3 first and see if you have the same
problems there.

Cheers,
Edi.



From stesch at no-spoon.de  Mon Aug 23 15:35:29 2004
From: stesch at no-spoon.de (Stefan Scholl)
Date: Mon, 23 Aug 2004 17:35:29 +0200
Subject: [tbnl-devel] Help needed in handler function with (sleep seconds)
In-Reply-To: <87d61hkhhx.fsf@bird.agharta.de>
References: <412A0575.9040305@paoloastori.com> <87d61hkhhx.fsf@bird.agharta.de>
Message-ID: <20040823153529.GY28866@parsec.no-spoon.de>

On 2004-08-23 17:21:14, Edi Weitz wrote:
> > mod_lisp for apache 2
> 
> There are several versions as far as I know.

Hmm.
http://www.fractalconcept.com:8000/public/open-source/mod_lisp/contrib/mod_lisp2-3.c
has a timeout of 1 second and all ap_reset_timeout() and
ap_kill_timeout() calls are commented out.

Haven't tried to understand the code, though. Just searched for
"timeout".


Regards,
Stefan





From maxi at paoloastori.com  Mon Aug 23 17:07:50 2004
From: maxi at paoloastori.com (Massimiliano Campagnoli)
Date: Mon, 23 Aug 2004 19:07:50 +0200
Subject: [tbnl-devel] Help needed in handler function with (sleep seconds)
Message-ID: <412A2466.5050006@paoloastori.com>

Stefan is perfectly right.

mod_lisp2-3.c has some problem in managing timeout.

where mod_lisp2-2.c (which is based on a different implementation) works 
has expected if the handler contains (sleep n).

But since mod_lisp2-2.c occasionally crashes Apache and has no support 
for the latest Edi's improvements
(since is based on mod_lisp 2.33) I would say that the option to move 
back to apache 1.3 with the latest mod_lisp.c 2.38  is still a good 
move, until someone (Marco Antoniotti & Co.) with enough experience has 
time to port and test mod_lisp.c 2.38 to Apache2.


Stefan Scholl wrote:

>On 2004-08-23 17:21:14, Edi Weitz wrote:
>  
>
>>>mod_lisp for apache 2
>>>      
>>>
>>There are several versions as far as I know.
>>    
>>
>
>Hmm.
>http://www.fractalconcept.com:8000/public/open-source/mod_lisp/contrib/mod_lisp2-3.c
>has a timeout of 1 second and all ap_reset_timeout() and
>ap_kill_timeout() calls are commented out.
>
>Haven't tried to understand the code, though. Just searched for
>"timeout".
>
>
>Regards,
>Stefan
>
>
>
>_______________________________________________
>tbnl-devel site list
>tbnl-devel at common-lisp.net
>http://common-lisp.net/mailman/listinfo/tbnl-devel
>
>  
>



-- 
ING. MASSIMILIANO CAMPAGNOLI

PAOLO ASTORI SRL
VIA MIRABELLA, 9
28013 - GATTICO 
ITALY





From xach at xach.com  Sat Aug 28 19:26:36 2004
From: xach at xach.com (Zach Beane)
Date: Sat, 28 Aug 2004 15:26:36 -0400
Subject: [tbnl-devel] setting non-string cookies?
Message-ID: <20040828192636.GB12869@xach.com>

I just started using tbnl. I am using TBNL 0.2.9, mod_lisp 2.38,
Apache 1.3.31, and SBCL 0.8.13.80. To test things, I created a small
page function:

   (defun xach-test ()
     (no-cache)
     (set-cookie "USERID" :value 1)
     (format nil "Testing, set cookie ~A" (cookie-in "USERID")))

I added this to the dispatch table with:

   (push (create-prefix-dispatcher "/username" 'xach-test) *dispatch-table*)

However, when I visited http://website/username, there was a delay of
several seconds and then a blank page was shown. This showed up in the
logs:

   [Sat Aug 28 15:12:06 2004] [warn] Could not send complete body to
   client, closing socket to Lisp

I changed the number 1 to the string "1", and the page came back
immediately with the expected answer.

The documentation says that cookie values are printed as with PRINC
when sending to the client. Does that mean that the number 1 should
work fine? If so, any thoughts on why it gives the blank page and
error log message?

Zach




From edi at agharta.de  Sat Aug 28 19:44:38 2004
From: edi at agharta.de (Edi Weitz)
Date: Sat, 28 Aug 2004 21:44:38 +0200
Subject: [tbnl-devel] setting non-string cookies?
In-Reply-To: <20040828192636.GB12869@xach.com> (Zach Beane's message of
	"Sat, 28 Aug 2004 15:26:36 -0400")
References: <20040828192636.GB12869@xach.com>
Message-ID: <87oekvdp3t.fsf@bird.agharta.de>

On Sat, 28 Aug 2004 15:26:36 -0400, Zach Beane <xach at xach.com> wrote:

> I just started using tbnl. I am using TBNL 0.2.9, mod_lisp 2.38,
> Apache 1.3.31, and SBCL 0.8.13.80. To test things, I created a small
> page function:
>
>    (defun xach-test ()
>      (no-cache)
>      (set-cookie "USERID" :value 1)
>      (format nil "Testing, set cookie ~A" (cookie-in "USERID")))
>
> I added this to the dispatch table with:
>
>    (push (create-prefix-dispatcher "/username" 'xach-test) *dispatch-table*)
>
> However, when I visited http://website/username, there was a delay of
> several seconds and then a blank page was shown. This showed up in the
> logs:
>
>    [Sat Aug 28 15:12:06 2004] [warn] Could not send complete body to
>    client, closing socket to Lisp
>
> I changed the number 1 to the string "1", and the page came back
> immediately with the expected answer.
>
> The documentation says that cookie values are printed as with PRINC
> when sending to the client. Does that mean that the number 1 should
> work fine? If so, any thoughts on why it gives the blank page and
> error log message?

You've caught a bug. The docs are wrong (should be "are URL-encoded"
instead of "are printed as with PRINC") and 0.2.9 didn't allow for
non-string cookie values. 0.2.10 does.

Thanks,
Edi.



From edi at agharta.de  Sat Aug 28 19:46:03 2004
From: edi at agharta.de (Edi Weitz)
Date: Sat, 28 Aug 2004 21:46:03 +0200
Subject: [tbnl-devel] New version 0.2.10
Message-ID: <87k6vjdp1g.fsf@bird.agharta.de>

Hi!

Get the newest release from:

  <http://weitz.de/files/tbnl.tgz>.

Here's the Changelog entry:

  Version 0.2.10
  2004-08-28
  Allow non-strings to be cookie values (bug caught by Zach Beane)

Edi.



From stesch at no-spoon.de  Sat Aug 28 20:59:38 2004
From: stesch at no-spoon.de (Stefan Scholl)
Date: Sat, 28 Aug 2004 22:59:38 +0200
Subject: [tbnl-devel] New version 0.2.10
In-Reply-To: <87k6vjdp1g.fsf@bird.agharta.de>
References: <87k6vjdp1g.fsf@bird.agharta.de>
Message-ID: <20040828205938.GY28832@parsec.no-spoon.de>

On 2004-08-28 21:46:03, Edi Weitz wrote:
>   Version 0.2.10

Well, all your stuff starts with "0.". So I'd say this is more a
Version 2.10 :-)






From edi at agharta.de  Sun Aug 29 06:38:20 2004
From: edi at agharta.de (Edi Weitz)
Date: Sun, 29 Aug 2004 08:38:20 +0200
Subject: [tbnl-devel] New version 0.2.10
In-Reply-To: <20040828205938.GY28832@parsec.no-spoon.de> (Stefan Scholl's
	message of "Sat, 28 Aug 2004 22:59:38 +0200")
References: <87k6vjdp1g.fsf@bird.agharta.de>
	<20040828205938.GY28832@parsec.no-spoon.de>
Message-ID: <87eklqcuub.fsf@bird.agharta.de>

On Sat, 28 Aug 2004 22:59:38 +0200, Stefan Scholl <stesch at no-spoon.de> wrote:

> Well, all your stuff starts with "0.". So I'd say this is more a
> Version 2.10 :-)

Hehe. That's a tough one. I think it's OK to start with "0." if you
have a brand-new, untested package. So I usually start with 0.1.0 and
increment that last number for minor changes and bug fixes and the
middle number for not-so-minor changes. Now, somebody has to decide
when the first version will start with "1." instead of "0." - hmmm...

We're certainly not there for TBNL yet. It's been out for a couple of
months only (although I've used similar stuff much longer) and it has
only half a dozen active users.

Maybe I might call CL-PPCRE "1.0.0" now but then again I should bump
the version number at a moment when there are no other changes in the
code. Sounds like a no-op to me. I'm glad I'm not in the marketing
department... :)

Cheers,
Edi.



From travis at crosswirecorp.com  Mon Aug 30 22:19:17 2004
From: travis at crosswirecorp.com (Travis Cross)
Date: Mon, 30 Aug 2004 17:19:17 -0500
Subject: [tbnl-devel] New version 0.2.10
In-Reply-To: <87eklqcuub.fsf@bird.agharta.de>
References: <87k6vjdp1g.fsf@bird.agharta.de>	<20040828205938.GY28832@parsec.no-spoon.de>
	<87eklqcuub.fsf@bird.agharta.de>
Message-ID: <4133A7E5.6080805@crosswirecorp.com>

Edi Weitz wrote:

>We're certainly not there for TBNL yet. It's been out for a couple of
>months only (although I've used similar stuff much longer) and it has
>only half a dozen active users.
>
>  
>
I have been following TBNL for two months now, so you should have at 
least a half a dozen + 1 active users... :)

There is a definate need for a project like this among those of us who 
build web applications in Lisp.  It doesn't make any sense for everyone 
to keep reinventing the wheel.

I have one question that I haven't seen come up on the mailing list or 
in the documentation:  what are the hurdles or considerations in 
implementing multipart form / file upload handling in TBNL ?

-- Travis



From jc at itsec.co.kr  Mon Aug 30 23:02:15 2004
From: jc at itsec.co.kr (Jong-won Choi)
Date: Tue, 31 Aug 2004 08:02:15 +0900
Subject: [tbnl-devel] New version 0.2.10
In-Reply-To: <4133A7E5.6080805@crosswirecorp.com>
References: <87k6vjdp1g.fsf@bird.agharta.de>	<20040828205938.GY28832@parsec.no-spoon.de>	<87eklqcuub.fsf@bird.agharta.de>
	<4133A7E5.6080805@crosswirecorp.com>
Message-ID: <4133B1F7.3050108@itsec.co.kr>

I have been using TBNL for exactly 3 months now. I just didn't want to 
tell it before finishing the development. No serious problem so far.
I'm writing web based application using TBNL(+ Apache + mod_lisp + 
CLSQL) with 2 colleagues (we're very serious :).

We wrote our own web framework on TBNL, and it works great. And yes we 
really like TBNL.

Thanks for TBNL! Without it I might use ugly portable Aserve(I've done 
it once already, so that is enough).

Cheers

Jong-won

Travis Cross wrote:

> Edi Weitz wrote:
>
>> We're certainly not there for TBNL yet. It's been out for a couple of
>> months only (although I've used similar stuff much longer) and it has
>> only half a dozen active users.
>>
>>  
>>
> I have been following TBNL for two months now, so you should have at 
> least a half a dozen + 1 active users... :)
>
> There is a definate need for a project like this among those of us who 
> build web applications in Lisp.  It doesn't make any sense for 
> everyone to keep reinventing the wheel.
>
> I have one question that I haven't seen come up on the mailing list or 
> in the documentation:  what are the hurdles or considerations in 
> implementing multipart form / file upload handling in TBNL ?
>
> -- Travis
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>
>



From stesch at no-spoon.de  Mon Aug 30 23:04:01 2004
From: stesch at no-spoon.de (Stefan Scholl)
Date: Tue, 31 Aug 2004 01:04:01 +0200
Subject: [tbnl-devel] New version 0.2.10
In-Reply-To: <4133A7E5.6080805@crosswirecorp.com>
References: <87k6vjdp1g.fsf@bird.agharta.de>
	<20040828205938.GY28832@parsec.no-spoon.de>
	<87eklqcuub.fsf@bird.agharta.de>
	<4133A7E5.6080805@crosswirecorp.com>
Message-ID: <20040830230401.GK28832@parsec.no-spoon.de>

On 2004-08-30 17:19:17, Travis Cross wrote:
> I have one question that I haven't seen come up on the mailing list or 
> in the documentation:  what are the hurdles or considerations in 
> implementing multipart form / file upload handling in TBNL ?

Make it just work or make it perfect. :-)

The whole MIME RFCs are somewhat complex. I'm really missing the
KISS principle there.

But there are libraries which implement multipart parsing that
are not perfect but work since years. I've read the code in
cgi.rb (CGI library of Ruby) and it's easy enough to be an
example for own implementations.





From edi at agharta.de  Tue Aug 31 05:47:26 2004
From: edi at agharta.de (Edi Weitz)
Date: Tue, 31 Aug 2004 07:47:26 +0200
Subject: [tbnl-devel] New version 0.2.10
In-Reply-To: <4133A7E5.6080805@crosswirecorp.com> (Travis Cross's message of
	"Mon, 30 Aug 2004 17:19:17 -0500")
References: <87k6vjdp1g.fsf@bird.agharta.de>
	<20040828205938.GY28832@parsec.no-spoon.de>
	<87eklqcuub.fsf@bird.agharta.de> <4133A7E5.6080805@crosswirecorp.com>
Message-ID: <873c236eq9.fsf@bird.agharta.de>

On Mon, 30 Aug 2004 17:19:17 -0500, Travis Cross <travis at crosswirecorp.com> wrote:

> I have one question that I haven't seen come up on the mailing list
> or in the documentation: what are the hurdles or considerations in
> implementing multipart form / file upload handling in TBNL ?

See Stefan's reply. My main problem is time. I haven't even found the
time to read through all the relevant RFCs. I also think that streams
(changing the encoding on the fly) might be an issue here.

This feature will probably have to wait until I need it in a project
or until someone else provides a working patch.

You might want to look at Jeff Caldwell's code at tbnl.org - I seem to
remember that he had started working on this. Jeff?

Cheers,
Edi.



From jdcal at yahoo.com  Tue Aug 31 10:52:22 2004
From: jdcal at yahoo.com (Jeff Caldwell)
Date: Tue, 31 Aug 2004 03:52:22 -0700 (PDT)
Subject: [tbnl-devel] File Upload Design Issues
Message-ID: <20040831105222.82165.qmail@web50607.mail.yahoo.com>

The code Edi referred to is only a proof of concept at
the moment. Don't bother looking at it yet. (See
below.) It did let me upload a file. I'm happy to look
at it again, though. There are things I need to
research, and I am asking for everyone's help and
advice so that I get the code as right as possible:

1) What are the relevant RFC's I need to consider?

2) What references/URLs/sample code is available for
me to learn about the encoding/stream issues?

3) General comments on the design. In particular,
uploading a file may only the first step. What is to
be done with the file? 

3a) There are OS dependencies, as not all OS's support
the same file names. 

3b) The file upload must generate a portable but
unique internal name while at the same time retaining
the OS-specific name specified by the sender (original
name). 

3c) This implies a kind of catalog of files, mapping
the original name to the internal name and vice versa.
This technique also is necessary to prevent duplicate
file names, for example from multiple users. 

3d) The user should be able to associate a short
and/or long description, and possibly a category or
two, with the file. TBNL might not dictate this
precisely but the catalog should be flexible in what
it holds.

3e) The catalog needs to be able to associate a file
with a user and vice versa. Users aren't a TBNL
concept at the moment and I'm not sure adding them
just for this is worthwhile. On the other hand,
uploading and storing files without the possibility of
a sense of ownership doesn't seem robust. Is this
really a part of the TBNL core? How can this be
handled cleanly?

3f) Where and how should the files be stored? ACS and
OpenACS (openacs.org), the last time I looked, store
uploaded files in a big directory tree with, IIRC,
subdirectories named with single letters. The
destination subdirectory was chosen by the first 3 or
4 chars of the internally-generated file name. The
idea is that a filesystem can have, or can efficiently
handle, only so many files per subdirectory. Given an
idea of the total number of uploaded files we want to
support, we could calculate the depth and number of
subdirectories needed.

3g) TBNL-level security is enough and it's OK to
mix uploaded files from several users in the same
catalog and subdirectories, so long as TBNL keeps
things sorted out and, depending upon the application,
the programmer is responsible for showing/making
available the right file to the right person.

I bet I both left something out and put too much in :)
I'd appreciate comments on all of the above. In
summary, how should the files be stored and how should
the catalog be structured? Once I have an idea of how
we think this should work, I'm happy to glue it all
together. Thanks for your help.

Jeff


--- Edi Weitz <edi at agharta.de> wrote:

> On Mon, 30 Aug 2004 17:19:17 -0500, Travis Cross
> <travis at crosswirecorp.com> wrote:
> 
> > I have one question that I haven't seen come up on
> the mailing list
> > or in the documentation: what are the hurdles or
> considerations in
> > implementing multipart form / file upload handling
> in TBNL ?
> 
> See Stefan's reply. My main problem is time. I
> haven't even found the
> time to read through all the relevant RFCs. I also
> think that streams
> (changing the encoding on the fly) might be an issue
> here.
> 
> This feature will probably have to wait until I need
> it in a project
> or until someone else provides a working patch.
> 
> You might want to look at Jeff Caldwell's code at
> tbnl.org - I seem to
> remember that he had started working on this. Jeff?
> 
> Cheers,
> Edi.
> 


		
_______________________________
Do you Yahoo!?
Win 1 of 4,000 free domain names from Yahoo! Enter now.
http://promotions.yahoo.com/goldrush



From stesch at no-spoon.de  Tue Aug 31 13:21:45 2004
From: stesch at no-spoon.de (Stefan Scholl)
Date: Tue, 31 Aug 2004 15:21:45 +0200
Subject: [tbnl-devel] Problems with SBCL 0.8.14
Message-ID: <20040831132145.GL28832@parsec.no-spoon.de>

Is anybody testing TBNL with SBCL 0.8.14, too? I get the
following with start-session (debugged the old way, due to the
lack of backtrace):

[Tue Aug 31 15:17:24 2004] [error] [TBNL] segmentation violation at #X985B0F0

I've inserted some (log-message :debug "....") to find the error.
It reaches the "before start-session", but not the "after
start-session" marker.


OK, I see if I can find something in TBNL. I really think this is
more a bug in SBCL and I don't have to find a solution for TBNL.
Instead I have to find a test case for SBCL.


Regards,
Stefan





From edi at agharta.de  Tue Aug 31 13:39:58 2004
From: edi at agharta.de (Edi Weitz)
Date: Tue, 31 Aug 2004 15:39:58 +0200
Subject: [tbnl-devel] Problems with SBCL 0.8.14
In-Reply-To: <20040831132145.GL28832@parsec.no-spoon.de> (Stefan Scholl's
	message of "Tue, 31 Aug 2004 15:21:45 +0200")
References: <20040831132145.GL28832@parsec.no-spoon.de>
Message-ID: <87u0uj77f5.fsf@bird.agharta.de>

On Tue, 31 Aug 2004 15:21:45 +0200, Stefan Scholl <stesch at no-spoon.de> wrote:

> Is anybody testing TBNL with SBCL 0.8.14, too?

Are you using a 2.6 kernel?



From stesch at no-spoon.de  Tue Aug 31 13:48:05 2004
From: stesch at no-spoon.de (Stefan Scholl)
Date: Tue, 31 Aug 2004 15:48:05 +0200
Subject: [tbnl-devel] Problems with SBCL 0.8.14
In-Reply-To: <87u0uj77f5.fsf@bird.agharta.de>
References: <20040831132145.GL28832@parsec.no-spoon.de>
	<87u0uj77f5.fsf@bird.agharta.de>
Message-ID: <20040831134805.GM28832@parsec.no-spoon.de>

On 2004-08-31 15:39:58, Edi Weitz wrote:
> On Tue, 31 Aug 2004 15:21:45 +0200, Stefan Scholl <stesch at no-spoon.de> wrote:
> 
> > Is anybody testing TBNL with SBCL 0.8.14, too?
> 
> Are you using a 2.6 kernel?

No. 2.4 kernel without NPTL backport.

But the code works fine in sbcl 0.8.13 and there are no threading
related comments in the changelog.

I'm currently looking into session.lisp:

    (log-message :debug "before make-instance of session")
    (setf session (make-instance 'session)
          (session *request*) session)
    (log-message :debug "after make-instance of session")

Doesn't reach the second debug message. Either the make-instance
or accessing the session slot of *request*.


There are some CLOS changes in the changelog of SBCL 0.8.14:

  * bug fix: improve the detection and resolution of MOP metacycles
    (where effective method computation depends on the generic function
    having its effective method computed).  (reported by Bruno Haible)

  * bug fix: pass the right initargs to :BEFORE or :AFTER methods on
    SHARED-INITIALIZE or INITIALIZE-INSTANCE in optimized
    MAKE-INSTANCE constructors.  (reported by Axel Schairer for cmucl)


Regards,
Stefan





From stesch at no-spoon.de  Tue Aug 31 14:47:47 2004
From: stesch at no-spoon.de (Stefan Scholl)
Date: Tue, 31 Aug 2004 16:47:47 +0200
Subject: [tbnl-devel] Problems with SBCL 0.8.14
In-Reply-To: <20040831134805.GM28832@parsec.no-spoon.de>
References: <20040831132145.GL28832@parsec.no-spoon.de>
	<87u0uj77f5.fsf@bird.agharta.de>
	<20040831134805.GM28832@parsec.no-spoon.de>
Message-ID: <20040831144747.GN28832@parsec.no-spoon.de>

On 2004-08-31 15:48:05, Stefan Scholl wrote:
>     (log-message :debug "before make-instance of session")
>     (setf session (make-instance 'session)
>           (session *request*) session)
>     (log-message :debug "after make-instance of session")
> 
> Doesn't reach the second debug message. Either the make-instance
> or accessing the session slot of *request*.

It's in function encode-session-string (session.lisp).

I tell more some time later today.


Regards,
Stefan






From stesch at no-spoon.de  Tue Aug 31 14:58:30 2004
From: stesch at no-spoon.de (Stefan Scholl)
Date: Tue, 31 Aug 2004 16:58:30 +0200
Subject: [tbnl-devel] Problems with SBCL 0.8.14
In-Reply-To: <20040831144747.GN28832@parsec.no-spoon.de>
References: <20040831132145.GL28832@parsec.no-spoon.de>
	<87u0uj77f5.fsf@bird.agharta.de>
	<20040831134805.GM28832@parsec.no-spoon.de>
	<20040831144747.GN28832@parsec.no-spoon.de>
Message-ID: <20040831145830.GO28832@parsec.no-spoon.de>

On 2004-08-31 16:47:47, Stefan Scholl wrote:
> On 2004-08-31 15:48:05, Stefan Scholl wrote:
> >     (log-message :debug "before make-instance of session")
> >     (setf session (make-instance 'session)
> >           (session *request*) session)
> >     (log-message :debug "after make-instance of session")
> > 
> > Doesn't reach the second debug message. Either the make-instance
> > or accessing the session slot of *request*.
> 
> It's in function encode-session-string (session.lisp).

(md5:md5sum-sequence "foo")

--> segmentation violation at #X926BC80

|sigh|