tbnl-devel

tbnl-devel@common-lisp.net

865 discussions

[hunchentoot-devel] Probably a bug in url-encode/url-decode
by Andrey Moskvitin 19 Mar '10

19 Mar '10

Hi, I encountered the following problem: CL-USER> (hunchentoot:url-decode "+") " " CL-USER> (hunchentoot:url-encode "+") "%2B" But in JavaScript: >>> encodeURI("+") "+" >>> decodeURI("+") "+" This is a bug? Andrey

4 7

[hunchentoot-devel] ht-wfx (widget framework)
by Phil Marneweck 18 Mar '10

18 Mar '10

Some time ago I suggested a simlple widget framework for hunchentoot and got a mixed bag of reaction. I have finally gotten round to creating something in that line. It is a thin layer over hunchentoot, but hopefully has enough functionality to help web development some what. Any feedback will be welcomed. http://bitbucket.org/harag/ht-wfx/wiki/Home

1 0

[hunchentoot-devel] Hunchentoot treatment of unhandled conditions
by Daniel Weinreb 02 Mar '10

02 Mar '10

We just ran into a problem regarding Hunchntoot's handling of unexpected conditions. Hunchentoot's accept-connections called usocket:socket-accept, which signaled a usocket:unknown-error. Nothing handled this condition. This happened in a server, which crashes (rather than going into the interactive debugger) when there is an unhandled condition. I'd like to have a way to do something like this in Hunchentoot. I see that the latest version goes further in this direction by having a handler-bind for "error" in the handle-request method. Unfortunately, in our case, the problem occurs before that is in effect. Are there any plans regarding this, or advice about it? Thanks. -- Dan

2 3

Re: [hunchentoot-devel] A potential Hunchentoot/Lispworks(?) fix
by Edi Weitz 21 Feb '10

21 Feb '10

[Cc to mailing list.] Thanks, that makes sense. I've applied your patch to the dev version. Edi. On Mon, Feb 15, 2010 at 11:58 PM, Matt Lamari <matt.lamari(a)gmail.com> wrote: > > (Thanks to Martin Simmons of Lispworks for this). > > > I'm still testing; but > in Acceptor.lisp > process-connection > > At the end - change it so, even if the force-output fails, the stream > will still be closed. > > (I'm still testing at my end - this took the leaking problem WAY down) > > > (when *hunchentoot-stream* > ;; as we are at the end of the request here, we ignore all > ;; errors that may occur while flushing and/or closing the > ;; stream. > (ignore-errors* > (force-output *hunchentoot-stream*)) > (ignore-errors* > (close *hunchentoot-stream* :abort t))) > > Edi Weitz wrote: >> On Thu, Feb 11, 2010 at 8:35 AM, Matt Lamari <matt.lamari(a)gmail.com> wrote: >> >> >>> Sorry to pester you privately; but I was wondering if you could verify >>> the leak on your Win32 Lispworks before I approach Lispworks. >>> >>> I don't know anyone else with a Win32 lispworks. >>> >> >> I'll be out of town for a week and I'm pretty busy right now. I >> wouldn't be able to test anything before end of next week. Maybe you >> should ask on the LW mailing list if you're unsure? There are lots of >> people there using Win32 LW... :) >> > >

1 0

[hunchentoot-devel] PATCH: Some minor fixes for cl-webdav under hunchentoot 1.0
by Matthew Curry 21 Feb '10

21 Feb '10

Edi, I took a look at it tonight anyway, and there where some obvious minor fixes I spotted right away, attached is a patch that gets (using cadaver) an initial connection, a put, and a get to work. Just functions that were renamed in the new hunchentoot. Delete doesn't work, complains about a handler-done tag being unknown (but thrown). Here's the message log entry: [2009-11-15 20:55:06 [ERROR]] attempt to THROW to a tag that does not exist: HANDLER-DONE I'm not too familiar with older versions of hunchentoot, does that ring a bell for you? I'll keep looking. -Matt

3 15

[hunchentoot-devel] hunchentoot-mp
by Patrick May 19 Feb '10

19 Feb '10

While looking for examples of locking within Hunchentoot, I came across a blog post from late 2007 that mentioned hunchentoot-mp and the make-lock / with-lock functionality. Is this still supported? Has it been renamed? Is there any documentation? Thanks, Patrick

2 3

[hunchentoot-devel] Cl-WebDAV broken?
by Ralf Mattes 18 Feb '10

18 Feb '10

Hello list, this is with a fresh svn checkout from: svn://bknr.net/svn/trunk/thirdparty/hunchentoot svn://bknr.net/svn/trunk/thirdparty/cl-webdav In a shell: cadaver http://localhost:4243/ triggers the following backtrace: The function (SETF HUNCHENTOOT:CONTENT-TYPE) is undefined. [Condition of type UNDEFINED-FUNCTION] Restarts: 0: [TERMINATE-THREAD] Terminate this thread (#<THREAD "Hunchentoot worker (client: 127.0.0.1:35255)" RUNNING {C164E19}>) Backtrace: 0: ((LAMBDA (SWANK-BACKEND::DEBUGGER-LOOP-FN)) #<FUNCTION (LAMBDA #) {AF28C2D}>) 1: (SWANK::DEBUG-IN-EMACS #<UNDEFINED-FUNCTION (SETF CONTENT-TYPE) {C1B8FF1}>) 2: (SWANK-BACKEND::CALL-WITH-BREAK-HOOK #<FUNCTION SWANK:SWANK-DEBUGGER-HOOK> #<CLOSURE (LAMBDA #) {C1B909D}>) 3: ((LAMBDA (SWANK-BACKEND::HOOK SWANK-BACKEND::FUN)) #<FUNCTION SWANK:SWANK-DEBUGGER-HOOK> #<CLOSURE (LAMBDA #) {C1B909D}>) 4: (SWANK::CALL-WITH-BINDINGS ..) 5: (SWANK::CALL-WITH-CONNECTION #<SWANK::CONNECTION {B366A09}> #<CLOSURE (LAMBDA #) {C1B909D}>) 6: (SWANK:INVOKE-SLIME-DEBUGGER #<UNDEFINED-FUNCTION (SETF CONTENT-TYPE) {C1B8FF1}>) 7: (SWANK-BACKEND::CALL-WITH-BREAK-HOOK #<FUNCTION SWANK:SWANK-DEBUGGER-HOOK> #<CLOSURE (LAMBDA #) {C1B907D}>) 8: ((LAMBDA (SWANK-BACKEND::HOOK SWANK-BACKEND::FUN)) #<FUNCTION SWANK:SWANK-DEBUGGER-HOOK> #<CLOSURE (LAMBDA #) {C1B907D}>) 9: (SWANK:SWANK-DEBUGGER-HOOK #<UNDEFINED-FUNCTION (SETF CONTENT-TYPE) {C1B8FF1}> #<unavailable argument>) 10: (INVOKE-DEBUGGER #<UNDEFINED-FUNCTION (SETF CONTENT-TYPE) {C1B8FF1}>) 11: ((SB-PCL::FAST-METHOD HUNCHENTOOT:MAYBE-INVOKE-DEBUGGER (T)) #<unavailable argument> #<unavailable argument> #<UNDEFINED-FUNCTION (SETF CONTENT-TYPE) {C1B8FF1}>) 12: (SIGNAL #<UNDEFINED-FUNCTION (SETF CONTENT-TYPE) {C1B8FF1}>)[:EXTERNAL] 13: (ERROR UNDEFINED-FUNCTION)[:EXTERNAL] 14: (SB-KERNEL::UNDEFINED-FUN-ERROR-HANDLER #<unavailable argument> #.(SB-SYS:INT-SAP #XB6561D10) #<SB-ALIEN-INTERNALS:ALIEN-VALUE :SAP #XB6561A1C :TYPE (* (STRUCT SB-VM::OS-CONTEXT-T-STRUCT))> (14)) 15: (SB-KERNEL:INTERNAL-ERROR #.(SB-SYS:INT-SAP #XB6561A1C) #<unavailable argument>) 16: ("foreign function: #x806726B") 17: ("foreign function: #x8052FE8") 18: ("foreign function: #x805872E") 19: ("foreign function: #x8056E2B") --more-- Is this a known problem? TIA Ralf Mattes

4 4

[hunchentoot-devel] Terminal problem when writing to binary request thread on LW32/Win32, under load
by Matt Lamari 11 Feb '10

11 Feb '10

This is part of a wider effort, to isolate a problem I've been having with my main app. I have written a standalone LW deliverable, all in one directory (with the libs used in subdirectories). It builds to an .EXE in LW5.1 or LW6 (2 batch files). I can't get the same feedback running in the IDE, except for the leaks. I am posting here to get assistance in converging on the solution. The problem I'm hitting may be in libraries, my usage of them, or lispworks itself (the problem in my wider app seems to trigger garbage-collector-level problems). The load tester is http://openwebload.sourceforge.net/ <-- I can get the problem to repeat with 1 connection or 100, default settings, against the dispatcher I listed below. It is my understanding that there are 2 ways for a Hunchentoot request handlers to emit data - returning a string, or by calling (send-headers) then writing to the returned stream. I have a bare-bones hunchentoot server that returns a page that is 100x the letter A. If I make it return the 100x A string, it will run indefinitely, and work fine. If I make it write binary 65 100 times with force-output, it grenades. Against a browser, BOTH WORK FINE. Against the load tester, the stream-write version leaks badly (even with the log turned off), spits a lot of errors, and eventually fails. The string version can run indefinitely, without errors or leaks. Obviously the load tester is disconnecting. But the important point is that it's exposing some scenario that is possible. Also, the failures I get in my main app have seemed to happen at the garbage collector level (a dump will be included below) I don't want to sweep this under the rug by accumulating a string, it may be highlighting a more serious problem in something more fundamental. Here is the hunchentoot dispatcher: The "return 100 As string" is there, commented out. Force-output on each byte is there to aggressively push the problem. Again let me state - this code works when interacting with a browser. And I expect an exception when the receiver disappears, just not one this critical. (setq *dispatch-table* (append (list (create-prefix-dispatcher "/" (lambda (&rest rest) #| (make-string 100 :initial-element #\A) |# (let ((stream (send-headers))) (loop for i from 1 to 100 do (progn (write-byte 65 stream) (force-output stream)))) (force-output stream) nil))) (list #'default-dispatcher))) This whole directory is self-contained and made of only the most minimal code (this is most of it) and the ASDF-loads. It includes a batch file that can build for LW5 and for LW6. I can hand it off to any interested party. If security is a concern, this core dispatch table is easily transplantable into anyone's working Hunchentoot environment. . . . Note the references to "CFO" and "MARK-GENERATION". I can provide the self-contained test project as a zipfile to anyone who wants it. Here is a sample error: *** EXCEPTION DATA *** code c0000005 flags 00000000 address 2015C250 EIP 2015c250 ESP 032fe62c EBP 032fe644 ESI 0000002e EDI 20bbfff2 EAX 00000140 EBX 0e84f0c1 ECX 0000007f EDX 00000100 stack dump: 032fe62c: 08048020 00001486 28b7bb52 28b7bb42 032fe63c: 00002e5e 00000480 032fe67c 204f61e3 032fe64c: 20b33b2d 20250d9b 20250d9b 20250d9b 032fe65c: 20250d9b 20250d9b 20250d9b 20250d9b 032fe66c: 20250d9b 00000c86 032fe684 2021142e 032fe67c: 032fe69c 20463860 08048020 20b33b2d 032fe68c: 20b33b1b 20746573 20b33b2d 20250d9b 032fe69c: 032fe6d8 20463c1d 20b33b1b ffffff96 032fe6ac: 032fe7d4 032fe6d8 20463c73 00000036 032fe6bc: 00000000 20b33b2d 20004003 2014bd33 032fe6cc: 20250d9b 200caac7 20b33b1b 032fe700 032fe6dc: 2046300c 00000084 200caac7 032fe70c 032fe6ec: 200caac7 200caac7 200caac7 200caac7 032fe6fc: 200caac7 032fe71c 207a8b92 20b33b1b 032fe70c: 00000100 00000056 032fe734 200caac7 032fe71c: 032fe72c 204e9f2e 20b33b1b 20b33b1b reentrypoint 200705e2 <**> Return address not inside a CFO : 20809a13 at 2efe78c ;>>>>> dumping 2efe70c [16] limit 2eff000 ;> 2efe70c: 100 200a3b07 2efe71c 20740488 ;> 2efe71c: 2efe728 204e5469 200a3b07 2efe740 ;> 2efe72c: 204eb9bb 84 fffffff6 2efe810 ;> 2efe73c: 200a3b07 2efe774 204e5622 201fc5c3 ;> 2efe74c: ffffff96 2efe7fc 2efe774 204e5639 ;> 2efe75c: 36 201fc5c3 20628823 200a3b07 ;> 2efe76c: 200a3b07 200a3ac3 2efe7a0 204aff5a ;> 2efe77c: 4 ffffff96 20b38561 201fc5c3 ;> 2efe78c: 20809a13 20b385fd 30 3000 ;> 2efe79c: 30 2efe7b8 204ab1b6 0 ;> 2efe7ac: 20b381da 20b28f03 20a0fb2f 2efe7d4 ;> 2efe7bc: 2073e8fe 20b28f03 20591a0b 206578f7 ;> 2efe7cc: 2efe7f1 206e89c7 2efe944 204af6ab ;> 2efe7dc: 1c 20b28f03 90ff8096 20155383 ;> 2efe7ec: 56 90ff8096 208098fb 2efe7e5 ;> 2efe7fc: ffffff96 2efe9b4 2efe944 204af738 Simple backtrace: 04ABFD30 20005170 #<Callable 2000511A> >>> Actually called : MARK-GENERATION 04ABFD3C 2000FACC #<Callable 2000FA1A> 04ABFD54 2006B742 #<Callable 2006B422> 04ABFD78 200343DA #<Callable 2003436A> 04ABFD98 20034926 #<Callable 2003487A> 033FE384 200345D6 #<Callable 200344A2> >>> Actually called : I-FULL-ALLOC-BLOCK-LOCAL 033FE394 20040EAE #<Callable 20040E8A> >>> Actually called : ALLOC-OBJECT 033FE3B8 2018BD98 "ALLOC-STRING" >>> Actually called : MAKE-BASE-STRING 033FE3D0 201AE864 "IN-MAKE-TYPED-STRING" 033FE3F8 201AEC11 "MAKE-TYPED-STRING" 033FE410 207E82E3 "MAKE-STREAM-BLOCK" 033FE430 207F27F5 "ADD-NEW-BLOCK" 033FE4BC 207F200D "(METHOD STREAM-FLUSH-BUFFER STRING-OUTPUT-STREAM . NIL)" >>> Actually called : STREAM-FLUSH-BUFFER 033FE4EC 20173123 "(METHOD STREAM-WRITE-STRING (BUFFERED-STREAM T))" 033FE518 207556D9 #<Callable 20755622> >>> Actually called : STREAM-WRITE-STRING 033FE540 20176744 "WRITE-STRING*" 033FE56C 20126821 "SUB-FORMAT" 033FE5B4 20125E72 "CALL-SUB-FORMAT" 033FE5D0 2084FE08 "FORMAT" 033FE674 204B0CE4 "SAFER-FORMAT" 033FE780 204B04CD "(METHOD DBG-PRINT-FRAME BINDING-FRAME . NIL)" 033FE7A8 2073E8FE #<Callable 2073E872> >>> Actually called : DBG-PRINT-FRAME 033FE7D4 204AF6AB "BUG-BACKTRACE" 033FE944 2044C5FA "PRINT-BACKTRACE-TO-STREAM" 033FE9AC 208243D0 "GET-BACKTRACE" 033FEA9C 20403292 "(METHOD HANDLE-REQUEST (ACCEPTOR REQUEST))" 033FEAB4 204BACC0 "SIGNAL" 033FEAF4 204CB948 "CONDITIONS-ERROR" 033FEB38 201EA995 "ERROR" >>> Actually called : SOCKET-ERROR 033FEB48 2043F73B "(METHOD STREAM-WRITE-BUFFER (SOCKET-STREAM T T T))" >>> Actually called : STREAM-WRITE-BUFFER 033FEB6C 20173AE9 "(METHOD STREAM-FLUSH-BUFFER BUFFERED-STREAM . NIL)" >>> Actually called : STREAM-FLUSH-BUFFER 033FEB88 20173A11 "(METHOD STREAM-FORCE-OUTPUT BUFFERED-STREAM . NIL)" >>> Actually called : FORCE-OUTPUT 033FEB94 207F21B5 "MAIN" 033FEBA8 2054562E "(METHOD HANDLE-REQUEST (ACCEPTOR REQUEST))" 033FEC70 2084A559 "(METHOD PROCESS-REQUEST T . NIL)" 033FED08 20409679 "(METHOD PROCESS-CONNECTION (ACCEPTOR T))" 033FEDBC 20566DF9 "NEXT-METHOD-CALL-2" 033FEDDC 204F7F37 "(METHOD PROCESS-CONNECTION AROUND (ACCEPTOR T))" 033FEE88 2076DE2E #<Callable 2076DDEA> 033FEEA8 2083B4A7 "PROCESS-SG-FUNCTION" 033FEFBC 204896A2 #<Callable 2048967A> 033FEFD0 20887C6B "(DEFINE-FOREIGN-CALLABLE NIL) . %FOREIGN-CALLABLE/thread_initial_function"

2 6

[hunchentoot-devel] after-listen-hook
by Faré 08 Feb '10

08 Feb '10

This patch, used at ITA, adds a hook whereby the server can notify future clients when it ready to listen, without said clients having to poll and/or introduce a race-condition. Please consider inclusion of this feature in next release of hunchentoot. Also, can you export WITHIN-REQUEST-P from the package? [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Resentment is like taking poison and waiting for the other person to die. — Malachy McCourt

2 1

[hunchentoot-devel] Hunchentoot web page gives error
by Faré 08 Feb '10

08 Feb '10

I'm experiencing the same error with Chromium, which is probably not any client to tell to go to hell. This page contains the following errors: error on line 2 at column 3: Char 0x0 out of allowed range Below is a rendering of the page up to the first error. Presumably, a lot of WebKit-based browsers will fail with the same error. Safari anyone? [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] For every complex problem, there is a solution that is simple, neat, and wrong. — H. L. Mencken

5 5

← Newer
1
...
19
20
21
22
23
24
25
...
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