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

Re: [hunchentoot-devel] Hunchentoot web page gives error
by Edi Weitz 02 Feb '10

02 Feb '10

Hi, Please follow up on the mailing list (see Cc). I can't see the error and I can't open your attachment. Which browser and OS are you using? Thanks, Edi. On Mon, Feb 1, 2010 at 12:36 PM, tczy <cy(a)wre.ath.cx> wrote: > Hi. > > http://www.weitz.de/hunchentoot/ > > gives the following: > > ===== > 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. > ===== > > -- > PGP/GnuPG keyID: D7AE1B98 > Key signature: 9D08 F20B C9CA 4174 5968 C0DE 9751 20F1 D7AE 1B98 >

3 4

[hunchentoot-devel] ht-simple-ajax
by Martin Loetzsch 02 Feb '10

02 Feb '10

Hi all, I recently posted here about HT-AJAX and Hunchentoot, which are kind of out of sync. I tried to make a patch for HT-AJAX that makes it compatible with newer versions of Hunchentoot, but I soon gave up because it seemed to me that a lot of functionality was already broken before Hunchentoot 1.0 came out. So I decided to make HT-SIMPLE-AJAX, which can do only 10% of what HT- AJAX could do. On the other hand, that's what I needed for GTFL (http://martin-loetzsch.de/gtfl ). And it's very elegant (only 150 loc) and works together with newer Hunchentoot versions: http://martin-loetzsch.de/ht-simple-ajax/ Hoping that somebody finds this useful, Martin Loetzsch

1 0

[hunchentoot-devel] silly issue with session and Hunchentoot due to warning
by Mackram Raydan 01 Feb '10

01 Feb '10

Hey Everyone, I am fairly certain that there must be an easy workaround to the issue I am experiencing but I might be blind to it. I am using Hunchentoot in the backend to handle a few things part of which is the session. Unfortuanetly it causes an error everytime I try to use the session I get a dump similar to this (I have cut it a bit to make more sense) 32SIGNAL 1. Couldn't write to #<SB-SYS:FD-STREAM for "standard error" {1002782181}>: Input/output error 31ERROR 1. SIMPLE-STREAM-ERROR 30SIMPLE-STREAM-PERROR 1. Couldn't write to ~s 2. #<FD-STREAM for "standard error" {1002782181}> 3. 5 23INTERPRET-FORMAT-LOGICAL-BLOCK 1. #&l t;SYNONYM-STREAM :SYMBOL SB-SYS:*STDERR* {1000148D21}> 2. (WARNING Session secret is unbound. Using Lisp's RANDOM function to initialize it.) 3. (WARNING Session secret is unbound. Using Lisp's RANDOM function to initialize it.) 4. 5. NIL 6. (#<~S> : #<~3i> #<~:_> #<~A>) 7. 8. T As you can see the problem is that it could not dump the warning on the standard output. My guess is that I should stop the warning but trying to do (setf hunchentoot:*log-lisp-warnings-p* nil) did not work with it. Can anyone suggest what i am missing? Mackram Raydan Company: www.imagimate.com Website: www.trailoflight.net "An invasion of armies can be resisted, but not an idea whose time has come." Victor Hugo On Thu, Jan 28, 2010 at 6:54 PM, Arjan Wekking <arjan(a)streamtech.nl> wrote: > On 28 jan 2010, at 15:57, Patrick May wrote: > > I don't think this is a Hunchentoot issue, but I thought I'd ask >> here first. I've noticed that Safari seems to cache the basic authorization >> username and password, so that even if I call (remove-session *session*) on >> the server side, Safari just reloads the page. >> > > As far as I know, Hunchentoot sessions have nothing to do with HTTP basic > authentication, of which Safari can indeed store the credentials in the OS X > Keychain (other browsers like Firefox or Chrome also allow you to 'save your > username and password' somewhere). > > All browsers actually 'cache' HTTP authentication credentials one way or > another between HTTP requests and usually forget them when you close the > window and/or tab that was authenticated [1]. This is not the same as > storing them in the Keychain but just part of how a HTTP authentication > 'session' works in browsers. > > Standard Hunchentoot sessions have nothing to do with HTTP authentication > unless you've re-implemented them to use HTTP authentication credentials as > session identifiers somehow (which would be an interesting approach but > that's not really relevant right now). > > > Am I interpreting the behavior correctly? If so, how do I force a >> re-authorization? >> > > With HTTP authentication, the simple anser is that you can't. Logging in > and out is under the HTTP client's control (where it in my opinion should > be). Unfortunately there's no good UI in browsers yet to gracefully log in > and out with HTTP authentication. Heck, you can't even see *if* your browser > is supplying any HTTP credentials without inspecting your own HTTP requests. > > Theoretically, you can do something like: > > (setf (return-code*) +http-authentication-required+) > > Which basically means that your webserver is telling the HTTP client that > whatever it supplied as credentials in the current request is not accepted > anymore (401 Unauthorized) and that it, in other words, should supply other > credentials. Some browsers will then clear the 'cached' credentials and ask > the user to supply new ones. > > This means that in browsers that do not store credentials, you will be > presented with a new 'please enter your username and password' dialog again, > right after logging out, and there's no way around this. I think Safari, in > this case, simply fetches them from the Keychain again and silently 'logs > in' again without the user even noticing, but I'm not entirely sure about > this. > > Either way, it's not a real solution. > > One thing that might work is to embed the Hunchentoot session ID into the > basic authentication 'realm', in which case (remove-session *session*) > actually works. But, by doing this, you effectively break the whole 'store > this username and password in my keychain' feature of Safari and similar > 'remember this username and password' features of all browsers, because the > browsers will store them along with the realm and when the realm changes, it > cannot reuse these stored credentials. > > The other way is to use cookie or URL based session and store the > authentication status in the server. This is where the Hunchentoot session > would come in and in this case you would probably need to build a simple > log-in HTML form, although it's possible to use HTTP authentication to > 'authenticate' the session as well and offer both a public login form and > HTTP authentication when directly accessing protected resources and still > have a 'log out' option that simply destroys or de-authenticates the session > server-side. > > I hope this all makes some sense :] > > -Arjan > > [1] http://en.wikipedia.org/wiki/Basic_access_authentication > _______________________________________________ > tbnl-devel site list > tbnl-devel(a)common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel >

1 1

[hunchentoot-devel] Authorization data being cached
by Patrick May 28 Jan '10

28 Jan '10

I don't think this is a Hunchentoot issue, but I thought I'd ask here first. I've noticed that Safari seems to cache the basic authorization username and password, so that even if I call (remove-session *session*) on the server side, Safari just reloads the page. Am I interpreting the behavior correctly? If so, how do I force a re-authorization? Thanks, Patrick

4 3

[hunchentoot-devel] Exception in USOCKET:GET-PEER-ADDRESS brakes ACCEPT-CONNECTIONS loop
by Anton Vodonosov 26 Jan '10

26 Jan '10

Hello, On one server running hunchentoot quite often the following error occurs: 23: (SB-IMPL::%WITH-STANDARD-IO-SYNTAX #) 24: (INVOKE-DEBUGGER #) 25: (ERROR SB-BSD-SOCKETS:NOT-CONNECTED-ERROR)[:EXTERNAL] 26: (SB-BSD-SOCKETS:SOCKET-ERROR "getpeername") 27: ((SB-PCL::FAST-METHOD SB-BSD-SOCKETS:SOCKET-PEERNAME (SB-BSD-SOCKETS:SOCKET)) # # #) 28: ((SB-PCL::FAST-METHOD USOCKET:GET-PEER-ADDRESS (USOCKET:STREAM-USOCKET)) # # #) 29: (HUNCHENTOOT::CLIENT-AS-STRING #) 30: ((SB-PCL::FAST-METHOD HUNCHENTOOT:HANDLE-INCOMING-CONNECTION (HUNCHENTOOT:ONE-THREAD-PER-CONNECTION-TASKMASTER T)) ..) 31: ((SB-PCL::FAST-METHOD HUNCHENTOOT:ACCEPT-CONNECTIONS (HUNCHENTOOT:ACCEPTOR)) # # #) 32: ((LAMBDA ())) As you see, it happens in USOCKET:GET-PEER-ADDRESS called in HANDLE-INCOMING-CONNECTION before the request handling thread is started. This exception breaks the main loop in ACCEPT-CONNECTIONS and server doesn't handle HTTP requests anymore. Most probably these errors are very rare in general, but on this particular machine they happen constantly. Adding ignore-errors to the loop helps - the server doesn't hang anymore. Best regard, - Anton P.S. The problem and the fix suggested are discovered by Andrey Moskvitin, I am just reporting it here.

3 4

[hunchentoot-devel] Returning a unicode string from a handler fails silently
by Ron Garret 23 Jan '10

23 Jan '10

Subject line says it all. If I have a handler that returns a string that has a non-ascii character in it then the handler fails silently. No headers. No log messages. No errors. No nothing. And as long as I'm at it, what does TBNL stand for? Thanks, rg

5 10

[hunchentoot-devel] Hunchentoot 1.1 + HT-Ajax
by Martin Loetzsch 14 Jan '10

14 Jan '10

Dear all, recent changes in Hunchentoot prevented ht-ajax from compiling. This is easy to fix locally, but I don't know what to do so that the version on this site also works: http://common-lisp.net/projecs/ht-ajax/ This is bad because a library of mine ( http://martin-loetzsch.de/ gtfl ) uses both hunchentoot and ht-ajax and people who try to install it will asdf:install with fail. Do you know who currently feels responsible for ht-ajax? Or who Mr or Mrs 'xlopez' on http://common-lisp.net/websvn/listing.php?repname=ht-ajax is? Or who to ask for changing the .tar.gz file on common-lisp.net? Thanks for your time, Martin Loetzsch

1 0

[hunchentoot-devel] Missing hunchentoot-test.asd in Hunchentoot 1.1.0
by Nico de Jager 11 Jan '10

11 Jan '10

Hi The tar archive of Hunchentoot 1.1.0 on weitz.de is missing the hunchentoot-test.asd file, which is surely by accident since the documentation still mentions it. Thanks for the new version! Nico

2 2

[hunchentoot-devel] New Hunchentoot release 1.1.0
by Edi Weitz 11 Jan '10

11 Jan '10

As pre-announced in December, Hunchentoot 1.1.0 is now out. Lots of changes, see documentation. Thanks to all who sent patches, suggestions, or bug reports. Happy New Year, Edi.

4 5

[hunchentoot-devel] Problem with LW6
by Jens Teich 09 Jan '10

09 Jan '10

Hunchentoot 0.15.6 when loading via asdf I get an error with LW6 where everything went smooth with LW5.1 [...] ; (DEFCLASS HUNCHENTOOT::SERVER) **++++ Error in HUNCHENTOOT:START-SERVER: WITHOUT-PREEMPTION is used ; HUNCHENTOOT:STOP-SERVER ; HUNCHENTOOT::PROCESS-CONNECTION ; HUNCHENTOOT::PROCESS-REQUEST ;; Processing Cross Reference Information ; *** 1 error detected, no fasl file produced. Warning: COMPILE-FILE warned while performing #<ASDF:COMPILE-OP NIL 21DACF73> on #<ASDF:CL-SOURCE-FILE "server" 21A6D5AB>. Warning: COMPILE-FILE failed while performing #<ASDF:COMPILE-OP NIL 21DACF73> on #<ASDF:CL-SOURCE-FILE "server" 21A6D5AB>. Error: erred while invoking #<ASDF:COMPILE-OP NIL 21DACF73> on #<ASDF:CL-SOURCE-FILE "server" 21A6D5AB> 1 (continue) Retry performing #<ASDF:LOAD-OP NIL 21A6850F> on #<ASDF:CL-SOURCE-FILE "server" 21A6D5AB>. 2 Continue, treating #<ASDF:LOAD-OP NIL 21A6850F> on #<ASDF:CL-SOURCE-FILE "server" 21A6D5AB> as having been successful. 3 (abort) Return to level 0. 4 Return to top loop level 0. Type :b for backtrace or :c <option number> to proceed. Type :bug-form "<subject>" for a bug report template or :? for other options. CL-USER 2 : 1 > :b Call to ERROR Call to CLOS::METHOD-COMBINATION-TEMPLATE Interpreted call to (METHOD ASDF:PERFORM :AROUND (ASDF:LOAD-OP ASDF:CL-SOURCE-FILE)) Call to CLOS::METHOD-COMBINATION-TEMPLATE Call to (SUBFUNCTION 1 ASDF:OPERATE) Call to ASDF:OPERATE Call to ASDF:OOS Interpreted call to ASDF Call to EVAL Call to CAPI::CAPI-TOP-LEVEL-FUNCTION Call to CAPI::INTERACTIVE-PANE-TOP-LOOP Call to MP::PROCESS-SG-FUNCTION CL-USER 3 : 1 >

3 2