- tbnl-devel@common-lisp.net - mailman3.common-lisp.net

[tbnl-devel] (post-parameters) strange behaviour ?
by Massimiliano Campagnoli 02 Sep '04

02 Sep '04

Try to handle this html form: <html> <body> <form name="my-form" action="/tbnl/form" method="post"> <input type=text name=":myfield" value="foo"> </form> </body> </html> after submitting this form in TBNL *debug-mode* you will get: > (post-parameters) > (("%3Amyfield" . "foo")) instead of >(("myfield" . "foo" )) Any explanation for this ? -- ING. MASSIMILIANO CAMPAGNOLI PAOLO ASTORI SRL VIA MIRABELLA, 9 28013 - GATTICO ITALY

3 3

[tbnl-devel] File Upload Design Issues
by Jeff Caldwell 01 Sep '04

01 Sep '04

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(a)agharta.de> wrote: > On Mon, 30 Aug 2004 17:19:17 -0500, Travis Cross > <travis(a)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

2 1

[tbnl-devel] New version 0.2.10
by Edi Weitz 31 Aug '04

31 Aug '04

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.

4 6

[tbnl-devel] setting non-string cookies?
by Zach Beane 28 Aug '04

28 Aug '04

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

2 1

[tbnl-devel] Help needed in handler function with (sleep seconds)
by Massimiliano Campagnoli 23 Aug '04

23 Aug '04

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

3 2

[tbnl-devel] Help needed in handler function with (sleep seconds)
by Massimiliano Campagnoli 23 Aug '04

23 Aug '04

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

2 1

[tbnl-devel] Re: Suggestion for a possible TBNL improvement
by Massimiliano Campagnoli 20 Aug '04

20 Aug '04

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

2 1

[tbnl-devel] Re: Suggestion for a possible TBNL improvement
by Edi Weitz 19 Aug '04

19 Aug '04

Hi! On Thu, 19 Aug 2004 16:02:14 +0200, Massimiliano Campagnoli <maxi(a)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.

1 0

[tbnl-devel] New version 0.2.9
by Edi Weitz 11 Aug '04

11 Aug '04

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.

1 0

[tbnl-devel] Authorized pages
by d95-bli＠nada.kth.se 10 Aug '04

10 Aug '04

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

3 6