tbnl-devel

tbnl-devel@common-lisp.net

865 discussions

[hunchentoot-devel] url-decode with Unicode text
by Andrei Stebakov 04 Sep '08

04 Sep '08

Let's say I have some Greek text in the url, which is encoded in utf-8. The string is "ελληνική". When the ht server receives the request with the string, it goes to url-decode with fails with the message: junk in string "%u03B5%u03BB%u03BB%u03B7%u03BD%u03B9%u03BA%u03AE" [Condition of type SB-INT:SIMPLE-PARSE-ERROR] It can be reproduced by evaluating: (HUNCHENTOOT:URL-DECODE "%u03B5%u03BB%u03BB%u03B7%u03BD%u03B9%u03BA%u03AE" (flex:make-external-format :utf-8 :eol-style :lf)) Backtrace: 0: (PARSE-INTEGER "%u03B5%u03BB%u03BB%u03B7%u03BD%u03B9%u03BA%u03AE")[:EXTERNAL] 1: (URL-DECODE "%u03B5%u03BB%u03BB%u03B7%u03BD%u03B9%u03BA%u03AE" #<FLEXI-STREAMS::FLEXI-UTF-8-FORMAT (:UTF-8 :EOL-STYLE :LF) {18422651}>) How can I decode Greek (or any other for that matter) text? I took Greek as an example as Latin/German text worked. Thank you, Andrew

3 15

[hunchentoot-devel] utf-8 encoding problems
by Andrei Stebakov 03 Sep '08

03 Sep '08

I have problems with some of the utf-8 characters in sbcl 1.0.18 and hunchentoot-0.15.7 (Ubuntu) When I create a handler like this: (defun test-handler () (no-cache) (recompute-request-parameters :external-format (flex:make-external-format :utf-8 :eol-style :lf)) (setf (hunchentoot:content-type) "text/html; charset=utf-8") (with-html-output-to-string (*standard-output* nil :prologue nil :indent nil) (:html (:head (:title "Test page")) (:body (:p ""quotation""))))) Where I have those "right and left quotation marks" I get an error: #\LEFT_DOUBLE_QUOTATION_MARK (code 8220) is not a LATIN-1 character. [Condition of type FLEXI-STREAMS:EXTERNAL-FORMAT-ENCODING-ERROR] If, on the other hand, I set global variable *hunchentoot-default-external-format* to utf-8 (setf *hunchentoot-default-external-format* (flex:make-external-format :utf-8 :eol-style :lf)) then everything works. I just want one handler to handle the uft-8 encoding, how can I fix it? Thank you, Andrew

3 10

[hunchentoot-devel] Request methods suffixed with * -- not backwards compatible?
by Chaitanya Gupta 03 Sep '08

03 Sep '08

Hi, I was trying to use the svn branch of Hunchentoot, and found, to my surprise, that most of my old code didn't work anymore. The culprit mainly seems to be request.lisp, where a lot of old functions/methods have been renamed with a * suffixed to their name. Are these changes permanent? Will these make it into the release version? Also, what is the reason behind this? I tried searching the mailing list for any discussion on this, but couldn't find anything. One more thing, there were no such changes to reply.lisp i.e. no *-suffixed names there. Will the reply methods also undergo these changes? Chaitanya

4 10

[hunchentoot-devel] Reading and writing additional cookies.
by Yarek Kowalik 27 Aug '08

27 Aug '08

I'm in the process of writing an application based on Weblocks. Weblocks uses Hunchentoot - I have been using version 0.11.1. I would like to set some application specific cookies. I would I go about doing that? My initial guess would be to setup a handler in the dispatch table and access (via special) the *reply* object to set the cookie using setf on cookies-out, and similarly access the *reqest* object to read the cookie value. Am I on the right track? Suggestions please. Thanks, Yarek

2 3

[hunchentoot-devel] Re: The old hunchentoot shared thread on openmcl bug
by Edi Weitz 18 Aug '08

18 Aug '08

Hi Mikel, Please send Hunchentoot question to the appropriate mailing list, see Cc. On Sun, 17 Aug 2008 06:08:54 -0500, mikel evins <mevins(a)mac.com> wrote: > Sorry to bother you with an old problem, but I'm stumbling over a > problem that is maybe an old one you're familiar with. I have a web > application built on Hunchentoot and cl-prevalence. I got fairly far > along and then ran into the problem where the lisp (Clozure CL) > process dies trying to write to a stream: > > Error: Stream #<BASIC-FILE-CHARACTER-OUTPUT-STREAM ("/Users/mikel/ > Valise/guild/trunk/src/ccl-src/ymra.world.db/transaction-log.xml"/6 > ISO-8859-1) #x30004294610D> is private to #<PROCESS hunchentoot- > worker-7(10) [Exhausted] #x300042944F8D> > > Presumably the cl-prevalence code that tries to write to the db is > using a stream that was created private in a different thread. Do > you remember where I should look for the code you used to fix this > for other cases? I'll track down the culprit and fix it; I was just > hoping to speed the process along by finding code that already did > the right thing somewhere. > > Thanks for any help. > > In case it's of interest, I'm using Hunchentoot 0.15.6 on Clozure CL > 1.2-r10477M-trunk with cl-prevalence 1.6. This looks like a CCL-specific problem not really related to Hunchentoot. Look at the :SHARING :LOCK keyword arguments to OPEN in log.lisp, maybe this'll help for your streams. Cheers, Edi.

1 0

[hunchentoot-devel] re: thread pool benchmark results
by Nick Allen 16 Aug '08

16 Aug '08

on Friday, July 18, 2008, 7:34:27 AM Hans wrote: > On Fri, Jul 18, 2008 at 03:00, Anton Vodonosov <avodonosov at yandex.ru> wrote: >> I have set up a little benchmark to test ithow >> thread pool may improve the hunchentoot performance. >> >> In two words it looks useful. Details are below. > [...] >> Patch for port-sbcl.lisp with the simple thread pool >> implementation is also attached. It is against 0.15.7, >> sorry it's not for the current development version of >> hunchentoot, but I created this thead pool code about >> half a year ago. > I think we would accept performance patches to the development > version. The revised connection management should make it easier to > integrate thread pooling in a portable fashion. I used pcall http://marijn.haverbeke.nl/pcall/ to make a portable thread-pool-powered connection manager (note: I don't have lispworks and I have no idea if pcall and lispworks work together since it uses bordeaux threads) darcs get http://common-lisp.net/project/bpm/darcs/pcall-connection-manager I think once the cl.net darcsweb script it might be browsable on the web at http://common-lisp.net/cgi-bin/darcsweb/darcsweb.cgi?r=bpm-pcall-connection… but I'm not 100% positive and I don't know how long it will take for it to be visible... note: in order to use it you have to add &ALLOW-OTHER-KEYS to the end of the parameters to HUNCHENTOOT:START-SERVER so it will accept the :CONNECTION-MANAGER-CLASS keyword arg anyways I tried to benchmark it against the one-thread-per-connection-manager on my laptop using siege. I used both the default dispatcher (the default hunchentoot landing page) and a dispatcher that returned a handler that slept for 3 seconds and returned a page (defun wait-for-3-seconds (hunchentoot:*request*) (lambda () (sleep 3) "this is the page")) with 3-5 threads in the pool the 1-thread-per-connection manager performed a lot better with both dispatchers. with 20-50 threads both connections managers had about the same performance with the 1-thread-per-connection manager being slightly faster. I'm sure there are better ways to benchmark it, but I'm not in a position to be playing with our server at the moment. I haven't taken a look at Anton's tests yet. Nick

2 2

[hunchentoot-devel] Is there a better way?
by Kevin Raison 08 Aug '08

08 Aug '08

I am trying to determine the best way to accomplish the following task and could use some help. I am writing a web-based (using hunchentoot, of course) application for managing voicemail that is stored in Cisco's Unity system. I can access the voicemail box of a given use via IMAP. The mel project has helped make that part easy. However, I am not sure the best way to send the audio stream to the user's browser. The method below illustrates (inefficiently) what I need to do. Can anyone suggest a more efficient method that does not use (send-headers)? The hunchentoot docs say, "If your handlers return the full body as a string or as an array of octets, you should not call this function." However, I cannot find an alternative way to do what I need to do. I must fetch the voicemail as an email via IMAP and then decode the base64-encoded body, which contains the voicemail as a wav file. Writing out a wav file and pointing the user's browser to it would introduce security issues, so I must do this entire process in memory. Any help is appreciated. (defmethod send-audio-stream ((user user) msg-id) "Convert the message body and send the wav content to the user." (handler-case (let ((msg (mel:find-message (mbox user) msg-id))) (setf (content-type) "audio/x-wav") (setf (header-out "Content-Disposition") (format t "inline; filename=~a.wav" msg-id)) (setf (content-length) ;; FIXME! Why do this twice? (length (base64-decode-msg-body-to-array msg))) (let ((stream (send-headers))) (base64-decode-msg-body-to-stream msg :stream stream))) (error (condition) (format nil "Unable to play message: ~a" condition)))) Cheers. Kevin Raison

3 8

[hunchentoot-devel] with-recursive-lock-held
by Nick Allen 31 Jul '08

31 Jul '08

Hello! Is the "ediware" location of the hunchentoot source the recommended version for deployment? or should we be using the tarball linked off the documentation or the "hans" version? I'm wondering because WITH-RECURSIVE-LOCK-HELD seems to have disappeared out of "lispworks.lisp", which seems to have introducing some bugs, which seems to me to suggests to me that the "ediware" repo is either out of date or too bleeding edge... take care Nick

2 4

[hunchentoot-devel] Hunchentoot behind apache http proxy (performance)
by Andrei Stebakov 25 Jul '08

25 Jul '08

The moment came when I had to move all of my site from being partially static http web pages to pages generated (or served from cached files) by Hunchentoot. The overall performance noticeably degraded in terms of response time. Even in cases when HT does nothing but serves a static file from its cache the response time increased from 0.3 sec to 1.5 sec (tested with httperf). I am running Apache 2 on Ubuntu (everything latest) with sbcl 1.0.18. I understand that when ht running behind the proxy the response time should increase. I wonder what can I do to optimize. Is it time to run HT as a standalone server? I still have a bunch of pages that I need to serve statically and lately my sbcl had problems with GC so it crashes time after time from heap exhaustion, so I am a bit uncomfortable to switch completely to Hunchentoot. I wonder how do you guys solve those problems? Thank you, Andrew

2 3

[hunchentoot-devel] Redirecting preserving the session?
by Andrei Stebakov 24 Jul '08

24 Jul '08

When I use redirect method it redirects to a new url and in the handler for the url I have no way of knowing the session of the url from where it was redirected. How can I send cookies along with redirecting to a new url?

2 3

← Newer
1
...
33
34
35
36
37
38
39
...
87
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

tbnl-devel