tbnl-devel

tbnl-devel@common-lisp.net

865 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] Confusing Hunchentoot behaviour
by Marijn Haverbeke 05 Nov '06

05 Nov '06

Hello, I am going to try to report something that looks like a bug, or maybe multiple bugs, but right now I am so bewildered that I'm not sure it's not something stupid I am doing... It all started when I was playing around with a lisp image and a Hunchentoot server, trying to get the hang of the library. When I added some things to *dispatch-table*, the server seemed to completely ignore me. (By the way, this is SBCL 0.9.18 on Linux behind mod_lisp). This was a bit frustrating. After poking the source for a bit, and making dispatch-request log the table it was getting, it turns out the server was using a value different from the current top-level *dispatch-table*. I assumed this was because it bound the result of calling *meta-dispatcher* to its own *dispatch-table* binding and apparently never left process-connections. I was about to write an email to this list about how this might not be the most desirable behaviour, but decided to test it one more time to make sure I wouldn't make a fool out of myself. And what do you know, after restarting my lisp process, starting a new server, and then messing with the *dispatch-table* it suddenly DID take my changes into account. 'What the hell', was what I thought. But it got even better. Refreshing the test page a few times showed that sometimes the changed *request-table* was used, but other times it would use the old one! I was about to dismiss Hunchentoot as a bug-ridden pile of weidness at this point. But while I was writing this incoherent complaint I finally got it -- obviously process-request is called once for every THREAD, and since the server will keep a bunch of (4 on my setup) long-lived listening threads when communicating with mod_lisp, strange results will occur when each of these has a different dispatch-table -- the same client will see different behaviour from the page. I'd say this is not a desirable feature. A good fix would be to just call *meta-dispatcher* for every call to dispatch-request, so that you've always got the most recent dispatch-table and the programmer can fiddle with that variable from the REPL and immediately see the result. Unless someone goes and writes a really complicated and expensive meta-dispatcher this shouldn't be a problem. -- As far as I can see no other parts of the code refer to the dynamic *dispatch-table* var, so losing that binding shouldn't be a problem. Let me know what you think. Marijn Haverbeke

2 4

[hunchentoot-devel] Re: Huchentoot
by Edi Weitz 01 Nov '06

01 Nov '06

Hi Bill! Thanks. I have no plans to add that to the code base, but I'm forwarding your email to the mailing list, so people can find it and try it out if they want. Cheers, Edi. On Wed, 1 Nov 2006 09:17:18 -0800, "William Bland" <doctorbill(a)gmail.com> wrote: > On 10/31/06, William Bland <doctorbill(a)gmail.com> wrote: >> >> Doh! Thanks Edi, of course that was it - sorry to have bothered you. >> >> I still can't get it to compile in my environment (SBCL on a MacBook) >> because it complains about the lack of threads, but I'm glad to at >> least know what I was doing wrong there! >> > > Hi again, > > I have Hunchentoot working now, in SBCL, on my MacBook. The changes I > had to make to port-sbcl.lisp were: > > 32c32 > < #-(and :sb-thread :sb-unicode) > --- >> #-sb-unicode > 34c34,38 > < (error "This library needs a version of SBCL with Unicode and > thread support.")) > --- >> (error "This library needs a version of SBCL with Unicode support.")) >> >> #-sb-thread >> (eval-when (:compile-toplevel :load-toplevel :execute) >> (warn "Without thread support, this library is only useful for development.")) > 67,69c71,74 > < (sb-thread:make-thread (lambda () > < (apply function args)) > < :name name)) > --- >> #+sb-thread(sb-thread:make-thread (lambda () >> (apply function args)) >> :name name) >> #-sb-thread(apply function args)) > > Of course it's not really useful for a production web server, but it's > great to be able to run the thing on my laptop for development before > I deploy to my server. > > I've tested all of the demos in hunchentoot-test. They appear to work > perfectly in my non-threaded environment. > > Cheers, > Bill. > -- > William Bland: http://www.abstractnonsense.org/ > Lisp documentation: http://www.lispdoc.com/

1 0

[hunchentoot-devel] Re: Huchentoot
by Edi Weitz 31 Oct '06

31 Oct '06

Hi Bill, [Cc to the mailing list.] On Tue, 31 Oct 2006 17:33:59 -0800, "William Bland" <doctorbill(a)gmail.com> wrote: > I'm trying to get Huchentoot installed - it seems like an excellent > server from everything I've read. Unfortunately I'm not able to get > past an ASDF error: > > CL-USER> (asdf:oos 'asdf:load-op :huchentoot-test) > ; loading system definition from > ; /Users/wjb/.sbcl/systems/huchentoot-test.asd into #<PACKAGE "ASDF0"> > ; registering #<SYSTEM :HUNCHENTOOT-TEST {12E80149}> as HUNCHENTOOT-TEST > > component "huchentoot-test" not found > [Condition of type ASDF:MISSING-COMPONENT] > > Restarts: > 0: [ABORT-REQUEST] Abort handling SLIME request. > 1: [ABORT] Exit debugger, returning to top level. > > Backtrace: > 0: (ASDF:FIND-SYSTEM :HUCHENTOOT-TEST T) > 1: (ASDF:OPERATE ASDF:LOAD-OP :HUCHENTOOT-TEST) > 2: (SB-INT:SIMPLE-EVAL-IN-LEXENV (ASDF:OOS (QUOTE ASDF:LOAD-OP) > :HUCHENTOOT-TEST) #<NULL-LEXENV>) > > My ASDF setup does work for all the other libraries I have set up > here (e.g. all the packages that huchentoot depends on). I > installed huchentoot simply by unpacking the tarball into > ~/.sbcl/.site and then making symbolic links for the two .asd files > from ~/.sbcl/systems > > Do you have any idea what might be going wrong? This is with SBCL > 0.9.17 on an Intel MacBook. If there's anything else I can look at > to help debug this, let me know and I'll do my best. If that's the real output from your Lisp session, then the solution probably is to use "Hunchentoot" instead of "Huchentoot." :) Cheers, Edi.

1 0

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

25 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

← Newer
1
...
62
63
64
65
66
67
68
...
87
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

tbnl-devel