tbnl-devel

tbnl-devel@common-lisp.net

865 discussions

[hunchentoot-devel] Scieneer Common Lisp
by Bob Krzaczek 09 Nov '09

09 Nov '09

Hi, I'm happy to say that I've managed to get most of Hunchentoot up and running on Scieneer Common Lisp (Solaris 10, SPARC, 64 bit) today, with fairly minimal tweaks to its dependencies' sources. Still, I've run into some problems. A handful of the hunchentoot-test pages are coming back with HTTP's Bad Request. So, although it's very promising, it isn't all quite there yet. Anyway, the main reason I'm writing to the list is to ask if anyone else is working on SCL, before I attack this in earnest tomorrow? I just didn't want to step on toes, or duplicate someone else's effort. Cheers, Bob -- Bob Krzaczek, Chester F. Carlson Center for Imaging Science, RIT phone +1-585-4757196, email krz(a)cis.rit.edu, icbm 43.0848N 77.6789W

2 1

[hunchentoot-devel] No REPL after hunchentoot:start
by quasi 06 Nov '09

06 Nov '09

Hey, I do not get the Slime REPL back after I start the webserver (hunchentoot:start (make-instance 'hunchentoot:acceptor :port 4242)) I am using the latest Slime from CVS. SBCL 1.0.29 x86-64 on MBP with snow leopard. It works with Allegro 8.1. Am I missing something trivial here? thanks for the help, regards quasi

3 3

[hunchentoot-devel] Preventing Hunchentoot from parsing the POST-Data
by Christoph Senjak 28 Oct '09

28 Oct '09

Hello. I am still trying to get PHP (and cgi in general) work behind Hunchentoot. The implementation of Cyrus Harmon does (besides not providing some necessary env-vars) not pass the postdata to the cgi-script. Using raw-post-data seems not to work (even when saying :want-stream nil) and always return nil as far as I saw. Can I somehow tell hunchentoot not to read and parse the post-data, but leaving raw-post-data as a binary stream which I can pass to the cgi-handler? Regards, Christoph

4 4

[hunchentoot-devel] [PATCH] maybe-read-post-parameters should pass `request' to raw-post-data
by Desmond O. Chang 28 Oct '09

28 Oct '09

--- source/hunchentoot/request.lisp | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/source/hunchentoot/request.lisp b/source/hunchentoot/request.lisp index 776113a..ed194c6 100644 --- a/source/hunchentoot/request.lisp +++ b/source/hunchentoot/request.lisp @@ -305,7 +305,7 @@ unknown character set ~A in request content type." (cond ((and (string-equal type "application") (string-equal subtype "x-www-form-urlencoded")) (form-url-encoded-list-to-alist - (split "&" (raw-post-data :external-format +latin-1+)) + (split "&" (raw-post-data :request request :external-format +latin-1+)) external-format)) ((and (string-equal type "multipart") (string-equal subtype "form-data")) -- 1.6.5

2 1

[hunchentoot-devel] Best way to run Hunchentoot on Port 80, Proxy-Module for Hunchentoot
by Christoph Senjak 19 Oct '09

19 Oct '09

Hello. As I am really annoyed by the confusing configuration-"possibilities" of apache, and as lighttpd doesnt support what I want to do in its stable release, I want to run hunchentoot in the first place. However, there are two problems: At first, I cannot run a usermode-process listening on port 80. I am using sbcl, so I could use sb-posix:setuid after starting hunchentoot and gaining port 80, removing root-privileges. Or I could forward port 80 to port 8000 via firewall policies. I would prefer the first possibility. The question is, if there is anything millitating against starting hunchentoot as root and then using setuid. I.e. any security issues that could result from it, anything that maybe wont work, etc. Another thing is the question if there is some proxy- or passthrough-module for hunchentoot. I still have some php-pages I want to host (even though I will use lighttpd rather than apache for this), and would therefore need to pass them to another server in the background. Regards, Christoph Senjak

4 7

[hunchentoot-devel] Customizing acceptor behaviour
by Sebastian Tennant 19 Oct '09

19 Oct '09

Hi there, I've managed to set up two acceptors which use different dispatch tables and write to different message log files by using packages and passing modified copies of LOG-MESSAGE-TO-FILE and LIST-REQUEST-DISPATCHER as keyword args when instantiating each acceptor (within each package). It works but there is a lot of code duplication going on so I decided to try and creating a third package (maytal) which does essentially the same thing in an abstracted way by subclassing TBNL:ACCEPTOR. I should point out that If I'm barking up the wrong tree entirely, it's because I'm new to CLOS (and relatively new to OOP in general). In short, I'm trying to create a package (maytal) which I can use in other packages like so: ;; set up and enter development environment package (in-package :cl-user) (defpackage "DEV-ENV" (:use :cl)) (in-package :dev-env) ;; dev-env::*dispatch-table* (defvar *dispatch-table* '()) ;; instantiate dev-env::*acceptor* (defvar *acceptor* (make-instance 'maytal::acceptor :port 49154 :msg-log-file "./messages/dev.log" :dispatch-table *dispatch-table*)) (tbnl:start *acceptor*) (msg 'info "DEV-ENV::*ACCEPTOR* started on port 49154") Here's my first stab at creating maytal: (in-package :cl-user) (defpackage "MAYTAL" (:use :cl)) (in-package :maytal) (defclass acceptor (tbnl:acceptor) ((msg-log-file :initarg :msg-log-file) (dispatch-table :initarg :dispatch-table))) (defmethod initialize-instance :after ((a acceptor) &key) ;; prepare local environment for closures (let ((mlf (slot-value a 'msg-log-file)) (dt (slot-value a 'dispatch-table))) ;; handy (i.e., short-name) message log function based on tbnl:log-message-to-file (defun msg (log-level format-string &rest format-arguments) (tbnl::with-log-file (stream mlf (tbnl::make-lock (symbol-name (gensym)))) (format stream "[~A~@[ [~A]~]] ~?~%" (tbnl::iso-time) log-level format-string format-arguments))) (setf (slot-value a 'tbnl::message-logger) 'msg) ;; annonymous request dispatcher function based on tbnl:list-request-dispatcher but ;; which uses a locally defined dispatch table variable (setf (slot-value a 'tbnl::request-dispatcher) (lambda (request) (loop for dispatcher in dt for action = (funcall dispatcher request) when action return (funcall action) finally (setf (tbnl:return-code tbnl:*reply*) tbnl:+http-not-found+))) )) Needless to say it doesn't work. The function 'msg' is defined in the maytal package rather than in the package which is current when an instance of maytal::acceptor is created (thus defeating the whole purpose of my efforts), and although the request dispatcher functions in different packages appear to use different dispatch tables, they don't actually work! ;;; (in-package :dev-env) (msg 'info "Acceptor ITI-DEV::*ACCEPTOR* started on port 49154") ;;; => Undefined function MSG called with arguments [...] (tbnl::acceptor-message-logger *acceptor*) ;;; => MAYTAL::MSG (tbnl::acceptor-request-dispatcher *acceptor*) ;;; => #<CCL:COMPILED-LEXICAL-CLOSURE (:INTERNAL (INITIALIZE-INSTANCE :AFTER (MAYTAL::ACCEPTOR))) #x91D16C6> Any and all help very much appreciated. Regards, Seb -- Emacs' AlsaPlayer - Music Without Jolts Lightweight, full-featured and mindful of your idyllic happiness. http://home.gna.org/eap

4 6

[hunchentoot-devel] acceptor-names not found
by Phil Marneweck 17 Oct '09

17 Oct '09

Has any body tried to use acceptor-names in hunchentoot define-easy-handler? I can only get the easy-handler to find the acceptor-name if I change (find (acceptor-name *acceptor*) acceptor-names :test #'eq)) to (find (acceptor-name *acceptor*) acceptor-names :test #'equal)) In the following function. (defun dispatch-easy-handlers (request) "This is a dispatcher which returns the appropriate handler defined with DEFINE-EASY-HANDLER, if there is one." (loop for (uri acceptor-names easy-handler) in *easy-handler-alist* when (and (or (eq acceptor-names t) (find (acceptor-name *acceptor*) acceptor-names :test #'eq)) .... As far as I have seen in my tests acceptor-names have to be strings(sequences) so changing eq to equal makes sense... Or am I smoking my socks again?

2 2

[hunchentoot-devel] Small patch for LispWorks 6 beta
by Nico de Jager 14 Oct '09

14 Oct '09

$ diff -u lispworks.lisp_orig lispworks.lisp_patched --- lispworks.lisp_orig 2009-09-30 11:42:22.000000000 +0200 +++ lispworks.lisp_patched 2009-09-30 19:06:22.118317238 +0200 @@ -90,14 +90,14 @@ (defun make-socket-stream (socket acceptor) "Returns a stream for the socket SOCKET. The ACCEPTOR argument is used to set the timeouts." - #-:lispworks5 + #+:lispworks4 (when (acceptor-write-timeout acceptor) (parameter-error "You need LispWorks 5 or higher for write timeouts.")) (make-instance 'comm:socket-stream :socket socket :direction :io :read-timeout (acceptor-read-timeout acceptor) - #+:lispworks5 #+:lispworks5 + #-:lispworks4 :write-timeout (acceptor-write-timeout acceptor) :element-type 'octet))

3 6

[hunchentoot-devel] Default external format
by Sebastian Tennant 12 Oct '09

12 Oct '09

Hi list, I don't often see messages of thanks on open source software mailing lists, so, without wishing to sound obsequious, let me buck the trend by thanking Edi, and everone else, before and since, for their work on hunchentoot. I've found that setting this at the top level of cl-user: (setf tbnl:*hunchentoot-default-external-format* tbnl::+utf-8+) has no effect, other than preventing an error when a handler produces non-ascii text, i.e., the non-ascii text is garbled when displayed in the browser, despite including the line: (setf (tbnl:content-type*) "text/html; charset=utf-8") in the handler. The problem is solved by also including the line: (setf (tbnl:reply-external-format tbnl:*REPLY*) tbnl::+utf-8+) in the handler, so what then is the purpose if the special variable? Am I missing something? Regards Seb -- Emacs' AlsaPlayer - Music Without Jolts Lightweight, full-featured and mindful of your idyllic happiness. http://home.gna.org/eap

4 8

[hunchentoot-devel] Constructing development and production environments
by Sebastian Tennant 24 Sep '09

24 Sep '09

Hi all, I'd like to instantiate two acceptors that use the standard log functions (LOG-MESSAGE-TO-FILE & LOG-ACCESS-TO-FILE) but with different values of *access-log-pathname* and *message-log-pathname* for each acceptor. One way is to define two (cloned) log functions with hardcoded pathnames and pass these log functions to MAKE-INSTANCE when instantiating each acceptor, but I'm wondering if there isn't a better (more Lispy) way to do it? I'd also welcome any advice/tips/pointers/suggestions people may have regarding how best to construct development and production environments within a single Hunchentoot process. Unfortunately my server is very low-powered and I don't have the resources to run two Hunchentoot processes. Regards, Sebastian -- Emacs' AlsaPlayer - Music Without Jolts Lightweight, full-featured and mindful of your idyllic happiness. http://home.gna.org/eap

1 0

← Newer
1
...
23
24
25
26
27
28
29
...
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