tbnl-devel October 2006

tbnl-devel@common-lisp.net

14 participants
18 discussions

[hunchentoot-devel] Problems with file uploads and mod_lisp
by Edi Weitz 07 Nov '06

07 Nov '06

Hi! I just realized that Hunchentoot in its current form has problems with file uploads if it's used behind mod_lisp. I could reproduce this with Apache 2 as well as Apache 1 and with LispWorks (but only on Linux, not on Windows) as well as with SBCL. To try this yourself, start the demo that comes with Hunchentoot and upload a couple of pictures (I used JPEGs) in the file upload section. Click on the uploaded pictures and view them. Symptoms that I see: - files are sometimes uploaded only partly - you see an Apache error message after an upload is finished (which usually means that mod_lisp can't talk to Lisp) - server gets completely unresponsive after some time It seems this is not deterministic, though. I've had situations where I uploaded the same picture a couple of times, and sometimes the whole file reached the server, sometimes only a part of it. One of the reasons for this that I could observe is that when rfc2388.lisp reads characters from the content stream, READ-CHAR sometimes returns NIL although the whole file hasn't been transferred yet (i.e. there should be more input available). I'm writing this because I haven't found the reason for this behaviour yet and I'll probably be too busy in the next days to do something about it. Obviously, I'd be happy if someone else would debug this and find a solution. Meanwhile, maybe you shouldn't use Hunchentoot with mod_lisp for production servers. The stand-alone version doesn't seem to be affected, though. Cheers, Edi.

2 4

[hunchentoot-devel] Bug Report: AUTHORIZATION
by Michael J. Forster 26 Oct '06

26 Oct '06

Hi Edi, I found a bug in AUTHORIZATION. If I click the "Authorization" link on the Hunchentoot test page and submit an empty username and password, instead of prompting me again, the server returns `Internal Server Error'. In this case, the call to SPLIT returns nil, which does not match the DESTRUCTURING-BIND lambda list. My first reaction was simply to rewrite the DESTRUCTURING-BIND to permit a nil username as well as password: (destructuring-bind (&optional user password) (split ":" (base64:base64-string-to-string (subseq authorization start))) (values user password)) Then, we would get (VALUES NIL NIL), which would seem consistent with the documentation. However, I also realised that AUTHORIZATION will return just nil if the auth header doesn't exist. Should that be documented? Here's my environment: * Hunchentoot 0.4.4 (no Apache, no mod_lisp) * latest versions (as of today) of dependencies * LispWorks 4.4.6 * OS X 10.4.8 * Safari 2.0.4 * Firefox 1.5.0.7 Regards, Mike P.S. Started migrating our apps from Portable AllegroServe to Hunchentoot this past week. Very pleased with the API and performance. Thanks! -- Michael J. Forster <mike(a)sharedlogic.ca>

3 3

[hunchentoot-devel] How to use/generate/access javascript/css?
by Vamsee Kanakala 23 Oct '06

23 Oct '06

Hi all, Sorry for the newbie questions, I'm curious as to how people working with tbnl/hunchentoot create/maintain their javascript and css files. If you use js/css generators, what are those (I know of only parenscript). If I'm using cl-who to generate my html, how can I include a .css or .js file in this code (or, where do I need to place these files to be accessible by hunchentoot? TIA, Vamsee.

2 2

[hunchentoot-devel] Comparisons with araneida?
by Jonathon McKitrick 18 Oct '06

18 Oct '06

Does anyone have any comments on tbnl (now Hunchentoot) and araneida? I'd be interested in anyone that switched from araneida, features comparisons, stability, idiosyncrasies and so on. Jonathon McKitrick -- My other computer is your Windows box.

1 0

Fwd: [hunchentoot-devel] Latest rfc2388
by Marijn Haverbeke 16 Oct '06

16 Oct '06

(Accidentally sent this just to Edi, forwarding to list) ---------- Forwarded message ---------- From: Marijn Haverbeke <marijnh(a)gmail.com> Date: Oct 16, 2006 12:38 PM Subject: Re: [hunchentoot-devel] Latest rfc2388 To: Edi Weitz <edi(a)agharta.de> It would be helpful if you could tell us what exactly is not working > for you, which Lisp you are using, etc. On close inspection, the problem is not with Hunchentoot or rfc2388. It turns out I was previously using an rfc2388 from a repository mainained by the UCW people, who have apparantly branched it and made a few incompatible changes. So you can safely ignore these messages. Regards, Marijn

2 1

[Marijn Haverbeke] Re: [hunchentoot-devel] Latest rfc2388
by Edi Weitz 16 Oct '06

16 Oct '06

Forwarded to mailing list.

1 0

[hunchentoot-devel] Latest rfc2388
by Marijn Haverbeke 16 Oct '06

16 Oct '06

Hello list, There appears to be some kind of incompatible interface change between the rfc2388 that can be found at cliki.net and the latest version of the library from common-lisp.net/project/rfc2388. After some head scratching I figured out that Hunchentoot was not working on my system because it uses the older version of rfc2388. So now I am switching between these versions of the library a lot, since UCW requires the other, newest version. Are there any plans to switch Hunchentoot to the latest version? Or do you wait until a new version is 'released'? I don't really know how the release process for rfc2388 works, or when a new version is due. Regards, Marijn

2 1

[hunchentoot-devel] Comparisons with araneida?
by Jonathon McKitrick 15 Oct '06

15 Oct '06

Hi all, the new release of Hunchentoot for other lisps piqued my interest. I've been deploying on araneida, but I've run into some issues that have required less than ideal workarounds. So, I just thought I'd check out Hunchentoot as an alternative. So for basic webapps with ajax functionality (XMLHttpRequest), how would you say the 2 platforms stack up? Jonathon McKitrick -- My other computer is your Windows box.

1 0

[hunchentoot-devel] New version 0.4.3 (Was: [Lispweb] Announcement: Hunchentoot)
by Edi Weitz 11 Oct '06

11 Oct '06

On Tue, 10 Oct 2006 22:24:27 +0000, Ralf Stoye <stoye(a)stoye.com> wrote: > I just tested Hunchentoot on osx openmcl (ppc) Might as well be that you're the first one... :) > + `(ccl::atomic-incf-decf ,place ,delta)) Ugh, another unexported symbol in the OpenMCL port. Well, we'll see what happens... Thanks for the patches - I've made a new release which incorporates them. > further i had to adjust the path to libssl in cl+ssl, in file > cl+ssl.asd, just below (defparameter *libssl-pathname*....) insert: > #+(and :openmcl :DARWIN-TARGET) > (setf *libssl-pathname* "/usr/lib/libssl.dylib") That should be sent to the cl+ssl maintainer. Cheers, Edi.

1 0

[hunchentoot-devel] New version 0.4.2
by Edi Weitz 10 Oct '06

10 Oct '06

ChangeLog: Version 0.4.2 2006-10-10 No timeouts for mod_lisp servers (as in Hunchentoot 0.3.x) Download: http://weitz.de/files/hunchentoot.tar.gz Cheers, Edi.

1 0

[hunchentoot-devel] New Hunchentoot version 0.4.0 (aka "good-bye TBNL")
by Edi Weitz 10 Oct '06

10 Oct '06

OK, as far as I am concerned, TBNL is hereby deprecated. If someone else wants to inherit and maintain it, they should contact me. I think that the current release of Hunchentoot (modulo errors) is a worthy successor/replacement for all implementations supported by TBNL. In particular, I expect less issues with SBCL due to the use of FLEXI-STREAMS. Please download, install, play with it, and report problems to the list: http://weitz.de/files/hunchentoot.tar.gz Note that some parts of the API have been slightly changed. Consult the docs if in doubt. And if you find mistakes in the documentation, please report them as well. Have fun, Edi.

2 2

[tbnl-devel] TBNL and SBCL
by David J. Neu 09 Oct '06

09 Oct '06

Hi, I know that there has been a lot of discussion about how nicely TBNL and SBCL play together, and as someone new to this list I wanted to ask a few question about the current situation. The architecture, I envision has Apache sitting "in-front", passing requests back to TBNL. In view of http://common-lisp.net/pipermail/tbnl-devel/2006-October/000710.html and http://common-lisp.net/pipermail/tbnl-devel/2006-October/000711.html do I understand correctly, that the new road ahead is that TBNL is sort of being "merged" with Hunchentoot to create an enhanced TBNL, that is less dependent on "other" packages and that this new release will reduce the issues related to TBNL/SBCL compatibility? Many thanks! Cheers, David

2 1

[tbnl-devel] Hunchentoot beta no. 4
by Edi Weitz 09 Oct '06

09 Oct '06

http://weitz.de/files/hunchentoot-beta.tar.gz Use at your own risk, as usual. FYI, I'm currently re-factoring the code (and changing parts of the API while I'm at it). I do this with LispWorks on Windows 99% of the time, so I'm not even sure if the code still compiles on SBCL or other Lisps. I'm happy if you send me notes about problems you're encountering. And, sorry, the documentation still hasn't been updated. Cheers, Edi.

3 6

[tbnl-devel] SBCL, hunchentoot, performance
by Graham Fawcett 06 Oct '06

06 Oct '06

Hi again folks, Maybe it's a bit early to be asking about hunchentoot, sbcl and performance... but heck, let me ask anyway. :-) Trying the hunchentoot beta on SBCL 0.9.17, I ran tbnl-test, and uploaded a ~0.75MB binary file. (Which worked!) Testing with 'ab', I downloaded the file -- but I wasn't able to get a download faster than 359KB/sec, or 2 seconds per download, on a fast network. I also observed >95% CPU activity during the download (about 50/50 between user and system). Profiling the :TBNL package, and downloading the file again, showed this: seconds | consed | calls | sec/call | name -------------------------------------------------------- 1.740 | 35,748,752 | 1 | 1.739901 | HANDLE-STATIC-FILE 0.004 | 8,184 | 1 | 0.003998 | TBNL::READ-HTTP-HEADERS 0.004 | 24,912 | 6 | 0.000665 | TBNL::WRITE-HEADER-LINE/HTTP and profiling :FLEX instead, then repeating the download, showed: seconds | consed | calls | sec/call | name ------------------------------------------------------------- 0.009 | 81,920 | 352 | 0.000027 | FLEXI-STREAMS::READ-BYTE* 0.000 | 106,051,824 | 1,488,124 | 0.000000 | FLEXI-STREAMS::WRITE-BYTE* The consing numbers seem pretty high. :-) I'm not sure how to interpret the 0.0 seconds for the write-byte* calls -- a hundred million conses might be fast, but not instantaneous! It's notable that the reported "profiling overhead" was ~15 seconds, perhaps it was just a profiling error. (I'm not a SLIME-profiling expert -- advice is welcome.) Is this degree of performance similar to what you see under Lispworks? I'm not throwing stones at beta code, just trying to interpret what I'm seeing here. Thanks, Graham

2 8

Re: [tbnl-devel] TBNL survey / re-org
by Edi Weitz 06 Oct '06

06 Oct '06

On Fri, 29 Sep 2006 18:16:26 -0400, Travis Cross <travis(a)officetone.com> wrote: > After you released Hunchentoot, I took a hard look at the source and > have been considering factoring out the non-portable code ever > since. I'd be terribly happy if you beat me to it though ;) There's a slight chance that this will happen... :) > Another project on my TBNL agenda that I started part way down was > seeing if I could remove some dependencies (primarily kmrcl) without > adding a whole lot a code to TBNL. LispWorks/Hunchentoot doesn't use KMRCL, so that's the plan for SBCL and the other Lisps as well. > Do you happen to be sold on the wonders of the Darcs version control > system? ;) If you're not strongly tied to whatever VCS you're > currently using, a public darcs repository could be a real boon. You wouldn't win anything, because I immediately make a new release if I add new code. Im the case of RDNZL I once tried with a public repository, but although several people had write access nothing came out of it. The only result was that it became harder for me and I couldn't work offline anymore... Cheers, Edi.

4 20

[tbnl-devel] tbnl, sbcl and binary uploads: still a problem?
by Graham Fawcett 04 Oct '06

04 Oct '06

Hi folks, Is anyone still encountering problems with binary uploads using TBNL with SBCL and the mod_lisp front-end? I've applied Travis Cross' patches to KMRCL and RFC2388. But in spite of the patches, I'm seeing errors when trying to upload a binary file to the tbnl-test demo application. For example: #<SB-SYS:FD-STREAM for "a constant string" {B7C2F69}> (:EXTERNAL-FORMAT :UTF-8): the octet sequence (226 227 207) cannot be decoded. I'm using SBCL 0.9.15 on Linux 2.6; TBNL 0.11.3, KMRCL-1.89, and a fresh RFC2388, with the Cross patches applied. *features* and SLIME backtrace are below. I'm happy to do more testing/debugging, but perhaps someone could help point me in the right direction. Thanks, Graham *features* (:CL-WHO :TBNL :TBNL-SBCL-DEBUG-PRINT-VARIABLE-ALIST :TBNL-BIVALENT-STREAMS :URL-REWRITE :KMR-NORMAL-DSDC :KMR-NORMAL-CESD :CL-PPCRE :KMR-MOP :ASDF :SB-THREAD :ANSI-CL :COMMON-LISP :SBCL :UNIX :SB-DOC :SB-TEST :SB-LDB :SB-PACKAGE-LOCKS :SB-UNICODE :SB-SOURCE-LOCATIONS :IEEE-FLOATING-POINT :X86 :ELF :LINUX :GENCGC :STACK-GROWS-DOWNWARD-NOT-UPWARD :C-STACK-IS-CONTROL-STACK :STACK-ALLOCATABLE-CLOSURES :ALIEN-CALLBACKS :LINKAGE-TABLE :OS-PROVIDES-DLOPEN :OS-PROVIDES-DLADDR :OS-PROVIDES-PUTWC) Snipped backtrace: 7: (TBNL::MAYBE-INVOKE-DEBUGGER #<SB-INT:STREAM-DECODING-ERROR {CFC3BC1}>) 8: (SIGNAL #<SB-INT:STREAM-DECODING-ERROR {CFC3BC1}>) 9: (ERROR SB-INT:STREAM-DECODING-ERROR) 10: (SB-INT:STREAM-DECODING-ERROR #<SB-SYS:FD-STREAM for "a constant string" {C6F56C1}> (226 227 207)) 11: (SB-IMPL::STREAM-DECODING-ERROR-AND-HANDLE #<SB-SYS:FD-STREAM for "a constant string" {C6F56C1}> 3) 12: (SB-IMPL::INPUT-CHAR/UTF-8 #<SB-SYS:FD-STREAM for "a constant string" {C6F56C1}> NIL NIL) 13: (READ-CHAR #<SB-SYS:FD-STREAM for "a constant string" {C6F56C1}> NIL NIL #<unused argument>) 14: ((FLET RFC2388::RUN) #<SB-SYS:FD-STREAM for "file /tmp/tbnl/tbnl-16" {CFC39B1}>) 15: (RFC2388::READ-UNTIL-NEXT-BOUNDARY #<SB-SYS:FD-STREAM for "a constant string" {C6F56C1}> "--------------------$ 16: ((SB-PCL::FAST-METHOD RFC2388:PARSE-MIME (STREAM T)) #<unavailable argument> #<unavailable argument> #<SB-SYS:$ 17: (TBNL::PARSE-RFC2388-FORM-DATA #<SB-SYS:FD-STREAM for "a constant string" {C6F56C1}> "multipart/form-data; bou$ 18: ((SB-PCL::FAST-METHOD INITIALIZE-INSTANCE :AFTER (TBNL::REQUEST)) (#(NIL 1 2 0 3 5 8 4 6) . #()) #<unavailable$ 19: ((LAMBDA (SB-PCL::|.P0.|)) #<unavailable argument>) 20: (TBNL::PROCESS-REQUEST (("content-stream" . #<SB-SYS:FD-STREAM for "a constant string" {C6F56C1}>) ("server-pr$ 21: (TBNL::LISTEN-FOR-REQUEST #<SB-SYS:FD-STREAM for "a constant string" {C6F56C1}> TBNL::PROCESS-REQUEST) 22: ((LAMBDA NIL))

4 7

[tbnl-devel] Flexi-streams needs a change for openmcl
by ocorrain＠yahoo.com 04 Oct '06

04 Oct '06

Hi-- OpenMCL runs into some problems with having +latin-1+ defined as a constant, since external-format doesn't have a load-form defined. I've added make-load-form to external-format.lisp in flexi-streams, thusly: --- external-format.lisp~ 2006-06-13 00:26:12.000000000 +0100 +++ external-format.lisp 2006-10-03 17:27:15.000000000 +0100 @@ -54,6 +54,15 @@ (:documentation "EXTERNAL-FORMAT objects are used to denote encodings for flexi streams.")) +(defmethod make-load-form ((self external-format) &optional env) + (declare (ignore env)) + `(make-instance 'external-format + :name ,(external-format-name self) + :id ,(external-format-id self) + :little-endian ,(external-format-little-endian self) + :eol-style ,(external-format-eol-style self))) + + (defun make-external-format% (name &key (little-endian *default-little-endian*) id eol-style) "Used internally by MAKE-EXTERNAL-FORMAT." -- Tiarnán

2 2

[tbnl-devel] Add hook before uploading a file.
by Erik Enge 02 Oct '06

02 Oct '06

My users will upload files as large as 500M to my servers. This will of course take awhile and I think it's asking for trouble to let them submit and then just let the browser sit there and spin a currently-working-cursor without any other feedback. So, I use an IFRAME and some Ajax to submit the form and also poll to see how the submittion is coming along. Then I report this to user in the form of a progress-bar. (Lots of examples of this, just search for "ajax upload progress" in Google.) Anyway, by default in TBNL, as far as I can tell, the request doesn't hit my code until after the file has been uploaded. What I think I really need instead is to have access to the temporary filename created for the upload (so I can track its size) right before TBNL starts reading the file. I've put this together locally by creating a hook in MAKE-TMP-FILE-NAME[1] which is simply called with the tmp-file-name created before returning. In my code I then use this filename to create data for the progress-bar. My question is whether there's a better way to achieve this and/or whether or not you want a patch. Thanks, Erik. [1] I think a comment explaining that it's called from the RFC2388 code would've been really helpful. :-)

3 6

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

tbnl-devel October 2006