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

[hunchentoot-devel] Re: versioning release tarballs
by Marijn Schouten (hkBst) 24 Aug '07

24 Aug '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Edi Weitz wrote: > On Tue, 10 Jul 2007 18:45:00 +0200, Stelian Ionescu <sionescu(a)common-lisp.net> wrote: > >> hello, would you be kind enough to put system versions in the >> tarball names of the releases you make or just make some symlinks ? >> I'm working on adding your latest releases to Gentoo and being able >> to download already-versioned tarballs would make our task easier > > Hi, > > I understand that this might make your work a little bit easier, but > it would be more work for me and it'd completely screw up the existing > workflow for two dozens of libs I maintain. So, no, I'm not going to > change this is in the near future. It seems to me that changing your scripts to: # remove old symlink rm hunchentoot.tar.gz # run original script <original script you use to produce hunchentoot.tar.gz> # add version and recreate symlink cp hunchentoot.tar.gz hunchentoot-VERSION.tar.gz ln -s hunchentoot-VERSION.tar.gz hunchentoot.tar.gz 1) would be simple, 2) cost you no more time to create tarballs, 3) whould be backwards compatible with all your workflow 4) would solve the problem not just for Gentoo, but for all people/distributions interested in distributing your packages, instead of gratuitously requiring each and every one of them to duplicate the work of versioning. I don't see how this simple change can ``completely screw up the existing workflow for two dozens of libs'', but I am hereby offering to do all of the work to make the required changes, so all you will need to do is point me to the scripts and judge the changes I will propose. > But as the download links from the weitz.de index page are generated > automatically and thus always look the same, it should be fairly easy > to write a small script that downloads the current tarballs and > renames them accordingly. If you would be willing to run this script and host the versioned tarballs, then I'm willing to write the script. sincerely, Marijn - -- Marijn Schouten (hkBst), Gentoo Lisp project <http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGzt4xp/VmCx0OL2wRAtFUAJ0cpyZHNUPLWC4mRh1MqPvOS8NhXQCdGCZD omOLZaWC+nx4fipTDKfjnCI= =QH4n -----END PGP SIGNATURE-----

1 0

[hunchentoot-devel] site structure
by Austin Haas 21 Aug '07

21 Aug '07

How does one generally structure their source files for a multi-sectioned site? I have a site that has several disparate sections, including: 1. main page, company information, etc. 2. portfolio of past works 3. client projects 4. various other interactive demos When I initially setup the project, I put the source files for each section into it's own directory, and included it as a module in my main defsystem. The main dispatch table would branch from there using "create-prefix-dispatcher" and call a "dispatcher" method belonging to the appropriate module. Each client project gets it's own source file and dispatcher, because they usually contain many unique sections themselves, such as pages for alpha demos, betas, etc. Some also need various dynamic features, too, so it's not as if I can just create some template system and pull unique data from a DB. I really need to be able to through up entirely new branches to the site on a weekly basis. The main issue that I've faced so far is that I have to add any new files to the :components section of the main defsystem method, which is inconvenient. It is very likely that I'm just not understanding the basics of setting up a lisp project, but I don't think most projects require the same structure as a large website. Please correct me if I'm mistaken. I'd appreciate any suggestions, pointers, or advice that anyone might have. Thanks. -austin -- Austin Haas Pet Tomato, Inc. http://pettomato.com

3 5

[hunchentoot-devel] preventing session-max-time updates
by timothy 21 Aug '07

21 Aug '07

Hello, I am using AJAX requests periodically on each page of my site to update a part of the display. These requests, however, prevent the session from becoming stale. Aside from fiddling with the last-click member of the session objects directly, what is the best way of keeping the periodic AJAX requests while letting unattended sessions become too-old-p? Thanks, Tim S

3 3

[hunchentoot-devel] Virtual hosts support using *META-DISPATCHER*
by Ram Krishnan 20 Aug '07

20 Aug '07

Hi all, I'm in the process of migrating a Web app from Portable Allegroserve to Hunchentoot (0.10), and I had a question about implementing virtual hosts by overriding the *META-DISPATCHER* function binding. Here's what I have so far: ---------------- (defvar *vhost-dispatch-table-map* (make-hash-table :test 'string=)) (defun vhost-meta-dispatcher (server) (declare (ignore server)) (or (gethash (hunchentoot:host) *vhost-dispatch-table-map*) *dispatch-table*)) (defun vhost-set-dispatch-table (hosts dispatch-table &key defaultp) (dolist (hostname (pg:mklist hosts)) (setf (gethash hostname *vhost-dispatch-table-map*) dispatch-table)) (when defaultp (setq *dispatch-table* dispatch-table))) (setq hunchentoot:*meta-dispatcher* 'vhost-meta-dispatcher) ---------------- Now, I'm able to return different *DISPATCH-TABLE* bindings based on the hostname, like so: ---------------- (vhost-set-dispatch-table "foo.bar.com" (list (hunchentoot:create-folder-dispatcher-and-handler "/assets/" #p"/var/www/foo.bar.com/assets/"))) (vhost-set-dispatch-table "quux.bar.com" (list (hunchentoot:create-folder-dispatcher-and-handler "/assets/" #p"/var/www/quux.bar.com/assets/"))) ---------------- Are there any problems in subverting the *META-DISPATCHER* binding this way? Is there a better alternative? Thanks. -ram

3 4

[hunchentoot-devel] Strange race condition?
by John Thingstad 20 Aug '07

20 Aug '07

I have just written a blog program. Functionally it is complete, but it contains a big and serious flaw. At intermittent intervals it gives a error like: [2007-08-18 09:05:58 [ERROR]] While accessing database #<CLSQL-MYSQL:MYSQL-DATAB ASE localhost/blog/jthing OPEN 219A8C6F> with expression "SELECT * FROM BLOG_ITEMS WHERE (ID = 224)": Error 2006 / MySQL server has gone away has occurred. It seems like a clsql error.. So why am I reporting it to here? Well the first thing to do is to isolate what is causing the error. After eliminating that the error was in my code (which included a rewrite) I found it down to the following lines: (with-html-output-to-string (*standard-output* nil :prologue t :indent t) (:html :xmlns "http://www.w3.org/1999/xhtml" (:head (:title (fmt "~A - ~A" (escape-string (getf blog :title)) (escape-string (getf item :title)))) (:link :href *blog-css-file* :rel "stylesheet" :type "text/css") (:link :href *tree-css-file* :rel "stylesheet" :type "text/css" :media "screen, projection") (:script :type "text/javascript" :src *tree-js-file* "") (:script :type "text/javascript" (fmt "~%addLoadListener( function() { treeMenu('~A', '~A'); });" "navigation" (format nil "~A?id=~D" (script-name) item-id)))) So it should be reported to cl-who right. Wrong! The problem isn't in the code that is generated. It appers to be the fact that I am including 2 css files and a javascript file. It is the UPLOAD of these from the client and the inerruption of the thread that causes the problem. Has anyone here experienced anything simular?

2 2

[hunchentoot-devel] unable to install hunchentoot on macosx (openmcl)
by Harsha Ch 11 Aug '07

11 Aug '07

hello all, i am trying to install hunchentoot on macosx 10.4.10(powerpc) using openmcl ,asdf-install , i am getting these errors, can anybody help me . thanks ;;; ASDF-INSTALL: Downloading 125037 bytes from http://weitz.de/files/hunchentoot.tar.gz to HUNCHENTOOT.asdf-install-tmp ... ;;; ASDF-INSTALL: Installing HUNCHENTOOT.asdf-install-tmp in /usr/local/asdf-install/site/, /usr/local/asdf-install/site-systems/ hunchentoot-0.11.1/ hunchentoot-0.11.1/CHANGELOG hunchentoot-0.11.1/CHANGELOG_TBNL hunchentoot-0.11.1/cookie.lisp hunchentoot-0.11.1/doc/ hunchentoot-0.11.1/doc/hunchentoot.gif hunchentoot-0.11.1/doc/index.html hunchentoot-0.11.1/doc/LICENSE.txt hunchentoot-0.11.1/easy-handlers.lisp hunchentoot-0.11.1/headers.lisp hunchentoot-0.11.1/hunchentoot-test.asd hunchentoot-0.11.1/hunchentoot.asd hunchentoot-0.11.1/log.lisp hunchentoot-0.11.1/mime-types.lisp hunchentoot-0.11.1/misc.lisp hunchentoot-0.11.1/packages.lisp hunchentoot-0.11.1/port-acl.lisp hunchentoot-0.11.1/port-cmu.lisp hunchentoot-0.11.1/port-lw.lisp hunchentoot-0.11.1/port-mcl.lisp hunchentoot-0.11.1/port-sbcl.lisp hunchentoot-0.11.1/README hunchentoot-0.11.1/reply.lisp hunchentoot-0.11.1/request.lisp hunchentoot-0.11.1/server.lisp hunchentoot-0.11.1/session.lisp hunchentoot-0.11.1/specials.lisp hunchentoot-0.11.1/test/ hunchentoot-0.11.1/test/favicon.ico hunchentoot-0.11.1/test/fz.jpg hunchentoot-0.11.1/test/packages.lisp hunchentoot-0.11.1/test/test.lisp hunchentoot-0.11.1/test/UTF-8-demo.html hunchentoot-0.11.1/unix-acl.lisp hunchentoot-0.11.1/unix-cmu.lisp hunchentoot-0.11.1/unix-lw.lisp hunchentoot-0.11.1/unix-mcl.lisp hunchentoot-0.11.1/unix-sbcl.lisp hunchentoot-0.11.1/util.lisp #P"/usr/local/asdf-install/site/hunchentoot-0.11.1/" #P"/usr/local/asdf-install/site/hunchentoot-0.11.1/" ; loading system definition from /usr/local/asdf-install/site-systems/hunchentoot.asd into #<Package "ASDF269"> ; registering #<SYSTEM :HUNCHENTOOT #x8454E16> as HUNCHENTOOT ; loading system definition from /usr/local/asdf-install/site-systems/url- rewrite.asd into #<Package "ASDF270"> ; registering #<SYSTEM :URL-REWRITE #x849908E> as URL-REWRITE ; loading system definition from /usr/local/asdf-install/site-systems/acl- compat.asd into #<Package "ASDF271"> ; registering #<SYSTEM ACL-COMPAT #x84B468E> as ACL-COMPAT ; loading system definition from /usr/local/asdf-install/site-systems/cl- ppcre.asd into #<Package "ASDF285"> ; registering #<SYSTEM :CL-PPCRE #x84C7FEE> as CL-PPCRE ; loading system definition from /usr/local/asdf-install/site-systems/puri.asd into #<Package "ASDF286"> ; registering #<SYSTEM PURI #x8409666> as PURI ; registering #<SYSTEM PURI-TESTS #x8401656> as PURI-TESTS ; loading system definition from /usr/local/asdf-install/site-systems/rfc2388.asd into #<Package "ASDF290"> ; registering #<SYSTEM :RFC2388 #x842EEAE> as RFC2388 ; loading system definition from /usr/local/asdf-install/site-systems/md5.asd into #<Package "ASDF291"> ; registering #<SYSTEM MD5 #x842627E> as MD5 ; loading system definition from /usr/local/asdf-install/site-systems/cl+ssl.asd into #<Package "ASDF292"> ; registering #<SYSTEM :CL+SSL #x843F34E> as CL+SSL ; loading system definition from /usr/local/asdf-install/site-systems/flexi- streams.asd into #<Package "ASDF293"> ; registering #<SYSTEM :FLEXI-STREAMS #x843623E> as FLEXI-STREAMS ; registering #<SYSTEM :FLEXI-STREAMS-TEST #x844D97E> as FLEXI-STREAMS-TEST ; loading system definition from /usr/local/asdf-install/site-systems/trivial-gray-streams.asd into #<Package "ASDF295"> ; registering #<SYSTEM :TRIVIAL-GRAY-STREAMS #x8441DF6> as TRIVIAL-GRAY-STREAMS ; loading system definition from /usr/local/asdf-install/site-systems/cffi.asd into #<Package "ASDF296"> ; registering #<SYSTEM CFFI #x8455376> as CFFI ; loading system definition from /usr/local/asdf-install/site-systems/cl- base64.asd into #<Package "ASDF298"> ; registering #<SYSTEM CL-BASE64 #x84756BE> as CL-BASE64 ; registering #<SYSTEM CL-BASE64-TESTS #x848CA3E> as CL-BASE64-TESTS ; loading system definition from /usr/local/asdf-install/site-systems/chunga.asd into #<Package "ASDF301"> ; registering #<SYSTEM :CHUNGA #x8481356> as CHUNGA > Error in process listener(1): Class named CCL::BASIC-STREAM not found. > While executing: FIND-CLASS > Type :POP to abort. Type :? for other options.

4 4

[hunchentoot-devel] ALIW (A Lisp in Wonderland) Wiki Project
by Volkan YAZICI 27 Jul '07

27 Jul '07

Hi all! I've just finished the wiki project[1] that I've been working on for some time. Project uses Hunchentoot as its web server (and lots of other EdiWare, e.g., cl-who, cl-ppcre, flexi-streams...) and I thought channel citizens would want to check it. [1] http://node2.core.gen.tr:8080/ And more important of all, thanks so much to Dr. Edmund Weitz for creating such great tools! Regards.

1 0

[hunchentoot-devel] Middleware with Hunchentoot
by Robert Uhl 21 Jul '07

21 Jul '07

>From Python's WSGI I've gotten the idea of middleware--that is, stuff which runs around user-defined code in some user-defined order. A null-effect middleware function might be defined like this: (defun null-effect (request next) (when next (funcall next request))) One can see how a middleware function could set things up for the user-defined handler, could decide whether or not to call the user's handler and could override whatever that handler returns. A convenience macro def-middleware might make it possible to write the null-effect function like this: (def-middleware null-effect (request) (call-next-middleware)) And the user might be able to create a dispatcher thus: (create-regex-dispatcher "/foo/bar?baz" (null-effect #'my-handler)) Obviously middleware could be chained: (create-regex-dispatcher "/foo/bar?baz" (authentication (caching #'my-handler))) Question: does this seem like a reasonable way to handle middleware, particularly authentication/authorisation mechanisms? I'm fairly new to Lisp, but it _seems_ like it's a fairly Lispy way to go about things. Thoughts? -- Robert Uhl <http://public.xdi.org/=ruhl> England really needs France around to provide comic relief. --Matt McLeod in comp.sys.mac.games.strategic

7 12

[hunchentoot-devel] host/port question
by Cyrus Harmon 18 Jul '07

18 Jul '07

I'm not sure what "the right thing" here is, but it struck me as odd that redirect didn't include a port argument, so I made the following changes to redirect: --- hunchentoot-0.9.0/misc.lisp 2007-03-30 14:01:27.000000000 -0700 +++ ../hunchentoot-0.9.0/misc.lisp 2007-04-27 22:45:00.000000000 -0700 @@ -229,6 +229,7 @@ (add-session-id (not (or host-provided-p (starts-with- scheme-p target) (cookie-in *session-cookie-name*)))) + port permanently) "Redirects the browser to TARGET which should be a string. If TARGET is a full URL starting with a scheme, HOST and PROTOCOL @@ -240,11 +241,11 @@ otherwise a 302." (let ((url (if (starts-with-scheme-p target) target - (format nil "~A://~A~A" + (format nil "~A://~A~@[:~A~]~A" (ecase protocol ((:http) "http") ((:https) "https")) - host target)))) + host port target)))) (when add-session-id (setq url (add-cookie-value-to-url url :replace-ampersands-p nil))) (setf (header-out :location) but then I realized that what we call "host" here really is host:port. Should these two notions be more "decoupled" or should I just think host:port when I see host? Thanks, Cyrus

2 4

[hunchentoot-devel] Hunchentoot standalone with and without ssl
by Austin Haas 12 Jul '07

12 Jul '07

If I am running Hunchentoot standalone with ssl, should it be able to handle requests that are NOT using ssl as well? Currently, I am getting the following error if I send a request to "http" and not "https": [2007-07-09 10:56:45 [ERROR]] Error while processing connection: A failure in the SSL library occurred on handle #.(SB-SYS:INT-SAP #X080EE6E0). (Return code: 1)SSL error queue: error:1407609C:SSL routines:SSL23_GET_CLIENT_HELLO:http request Do people normally start two servers, one w/ ssl and one w/o, if they want to be able to handle both types of requests? The requests would be to different resources, obviously. -austin -- Austin Haas Pet Tomato, Inc. http://pettomato.com

4 4