tbnl-devel March 2013

tbnl-devel@common-lisp.net

6 participants
10 discussions

[hunchentoot-devel] 404 page
by Patrick May 08 May '14

08 May '14

I'm sure I'm overlooking something simple in the documentation, but I've Googled madly and not found the answer. How do I specify my own 404 page in Hunchentoot? Thanks, Patrick

4 13

[hunchentoot-devel] CLOSE_WAIT and errcode 24 (too many files) when using https
by Lucas Hope 31 Mar '13

31 Mar '13

Hi there, This is a bug report. I'm using Hunchentoot 1.2.2 from quicklisp. I encountered a server resource limit due to (I think) http connections on an https port. Cliffs notes: https server is not hanging up properly when a connection is attempted using normal http. This eventually causes the process to hit a kernel socket limit. Details: I recently upgraded my hunchentoot webserver from http to full ssl/https. The webservice runs on a dedicated port, and I left the port the same. We had a monitoring service running to check the server was alive. However the monitoring service wasn't updated to use https. So every half an hour or so, we got: [2013-03-26 06:49:26 [ERROR]] Error while processing connection: A failure in the SSL library occurred on handle #.(SB-SYS:INT-SAP #X04B69660) (return code: 1). SSL error queue: error:1407609C:SSL routines:SSL23_GET_CLIENT_HELLO:http request Also, if I connect myself using http instead of https, the browser connection times out. The server certainly doesn't hang up instantly like I'd expect. Last night, my webserver listener threw a bsd socket error - code 24 (too many files). When I ran an lsof of the process, there were a large number of long term CLOSE_WAIT connections, which my internet research tells me is due to the server not closing connections properly. I think the connections piled up, and I thus hit the socket limit for that process. Anyone else have that issue? Is it an easy fix? Cheers, -Luke

2 2

[hunchentoot-devel] 404 (page not found) leads to 500 (internal server error)
by Sebastian Tennant 31 Mar '13

31 Mar '13

Hi Hans, While investigating the effect of subclassing ACCEPTOR-STATUS-MESSAGE, I came across this behaviour: CL-USER> (load "srv.lisp") The value 404 is not of type SEQUENCE. [Condition of type TYPE-ERROR] --8<---------------cut here---------------start------------->8--- ;;; srv.lisp (in-package "CL-USER") (asdf:load-system :hunchentoot) (asdf:load-system :drakma) (setq tbnl:*catch-errors-p* nil) (tbnl:start (make-instance 'tbnl:acceptor :document-root nil :error-template-directory nil :address "127.0.0.1" :port 50000)) (write (drakma:http-request "http://127.0.0.1:50000")) --8<---------------cut here---------------end--------------->8--- I've set TBNL:*CATCH-ERRORS-P* to NIL so that you drop into the debugger. This shows that the call (START-OUTPUT 404 ...) results in a (LENGTH 404) call, which is what fails, but it's not obvious (at least not to me) where this LENGTH call is coming from. Sebastian -- Emacs' AlsaPlayer - Music Without Jolts Lightweight, full-featured and mindful of your idyllic happiness. http://home.gna.org/eap

3 4

[hunchentoot-devel] Hunchentoot 1.2.14
by Hans Hübner 30 Mar '13

30 Mar '13

Hi, I have just released Hunchentoot 1.2.14. This release changes how ACCEPTOR-STATUS-MESSAGE is called. Previously, ACCEPTOR-STATUS-MESSAGE was invoked for all requests, after the handler had been invoked. If it returned non-NIL, the content returned by the handler was discarded. This did not actually make sense, and I have changed it so that ACCEPTOR-STATUS-MESSAGE is only called when the handler did not return contents. That way, handlers are now free to create their own status message bodies, if desired. This is a incompatible change, so if you depended on the previous invocation sequence, please review your code before upgrading. The work was funded by Ron Garret, thanks for that! -Hans

2 2

Re: [hunchentoot-devel] [drakma-devel] Error while trying to POST some JSON data
by Hans Hübner 22 Mar '13

22 Mar '13

You can check out the latest cl+ssl - which contains a fix for the problem: cd ~/quicklisp/local-projects/ git clone git://gitorious.org/cl-plus-ssl/cl-plus-ssl.git Quicklisp will automatically find cl+ssl from that location. Remember to remove that checkout after you've upgraded to a newer quicklisp release that has the fix in the future. -Hans On Thu, Mar 21, 2013 at 10:54 PM, Peter Kuchta <peter(a)kuchta.co.uk> wrote: > Kevin, > > Thank you very much - I was absolutely sure I was doing something wrong! > > Could you please show how I can roll back to cl+ssl-20130128-git ? I don't > know how to do it, I'm a quicklisp newbie. > > Many thanks, > Piotr > > On Thu, Mar 21, 2013 at 9:44 PM, Kevin Raison <raison(a)chatsubo.net> wrote: > >> I encountered this same error after upgrading packages via quicklisp. I >> rolled back cl+ssl to version cl+ssl-20130128-git and the problem went >> away. I have not had time to investigate further yet. >> >> -Kevin >> >> >> On 03/21/2013 02:41 PM, Peter Kuchta wrote: >> > Hi everybody, >> > >> > I'm trying to POST some JSON data to a web service: >> > >> > (ql:quickload :st-json) >> > (ql:quickload :cl-json) >> > (ql:quickload :drakma) >> > >> > (defvar *rc* (merge-pathnames (user-homedir-pathname) ".apirc")) >> > >> > (defvar *user* >> > (with-open-file (s *rc*) >> > (st-json:read-json s))) >> > >> > (defvar api-url (st-json:getjso "url" *user*)) >> > (defvar api-key (st-json:getjso "key" *user*)) >> > (defvar api-email (st-json:getjso "email" *user*)) >> > >> > (setf drakma:*header-stream* *standard-output*) >> > >> > (defvar *req* '(("dataset" . "tigge") >> > ("step" . "24") >> > ("date" . "20071001") >> > ("time" . "00") >> > ("origin" . "all"))) >> > >> > (format t "json:~S~%" (json:encode-json-to-string *req*)) >> > >> > (defun retrieve (api request) >> > (let* ((cookie-jar (make-instance 'drakma:cookie-jar)) >> > (extra-headers (list (cons "From" api-email) >> > (cons "X-API-KEY" api-key))) >> > (url (concatenate 'string api-url api "/requests")) >> > (stream (drakma:http-request url >> > :additional-headers extra-headers >> > :accept "application/json" >> > :method :post >> > :content-type "application/json" >> > :external-format-out :utf-8 >> > :external-format-in :utf-8 >> > :redirect 100 >> > :cookie-jar cookie-jar >> > :content (json:encode-json-to-string >> request) >> > :want-stream t))) >> > (st-json:read-json stream))) >> > >> > (retrieve "/datasets/tigge" *req*) >> > >> > Unfortunately, I get an error, although the data seems to be encoded OK >> > to JSON and the headers generated by drakma too, I think. Apparently >> > something is wrong with the :content (the list of integers in the errors >> > message is just the list of ASCII codes of the JSON encoded data). >> > >> > >> > >> json:"{\"dataset\":\"tigge\",\"step\":\"24\",\"number\":\"all\",\"levtype\":\"sl\",\"date\":\"20071001\",\"time\":\"00\",\"origin\":\"all\",\"type\":\"pf\",\"param\":\"tp\",\"area\":\"70\\/-130\\/30\\/-60\",\"grid\":\"2\\/2\",\"target\":\"data.grib\"}" >> > >> > POST /v1/datasets/tigge/requests HTTP/1.1 >> > Host: api.service.int <http://api.service.int> >> > User-Agent: Drakma/1.3.0 (SBCL 1.1.5; Darwin; 12.2.0; >> > http://weitz.de/drakma/) >> > Accept: application/json >> > Connection: close >> > From: me(a)gmail.com <mailto:me@gmail.com> >> > X-API-KEY: 19a0edb6d8d8dda1e6a3b21223e4f86a >> > Content-Type: application/json >> > Content-Length: 193 >> > >> > >> > debugger invoked on a SIMPLE-TYPE-ERROR: >> > The value of CL+SSL::THING is #(123 34 100 97 116 97 115 101 116 >> > 34 58 34 >> > ...), which is not of type >> (SIMPLE-ARRAY >> > >> > (UNSIGNED-BYTE 8) >> > (*)). >> > >> > Any idea what's wrong with this code? Many thanks in advance. >> > >> > Best regards, >> > Piotr >> > >> > >> > _______________________________________________ >> > drakma-devel mailing list >> > drakma-devel(a)common-lisp.net >> > http://lists.common-lisp.net/cgi-bin/mailman/listinfo/drakma-devel >> > >> > > > _______________________________________________ > drakma-devel mailing list > drakma-devel(a)common-lisp.net > http://lists.common-lisp.net/cgi-bin/mailman/listinfo/drakma-devel > >

1 0

Re: [hunchentoot-devel] [hunchentoot] start thread (#52)
by Hans Hübner 22 Mar '13

22 Mar '13

Fare, I like the general idea, but I think it would be better to encapsulate the actual thread starting in Hunchentoot. The patch you proposed puts the burden of starting threads onto the user. I would suggest: (defgeneric make-thread-function (taskmaster thunk) (:method ((taskmaster t) thunk) thunk))) I like the general simplification with the introduction of start-thread, but that GF should not be part of the public interface. Also, the arguments should be (taskmaster thunk &key name). I see no reason to leave the argument list open as start-thread is meant to be called only from within Hunchentoot. Documentation updates are missing. Let me know what you think. -Hans On Thu, Mar 21, 2013 at 8:54 PM, François-René Rideau < notifications(a)github.com> wrote: > Introduce start-thread as an entry point so specialized taskmasters > can wrap bindings and condition handlers around hunchentoot new thread > thunks. > > Note that LispWorks and non-LispWorks should probably do the same thing > wrt starting a thread for the acceptor or not. I chose to always start a > thread, as per the non-LispWorks default. That choice could be reversed. > But it's probably bad practice to let the LW and non-LW versions diverge on > such a point. > ------------------------------ > You can merge this Pull Request by running > > git pull https://github.com/fare/hunchentoot master > > Or view, comment on, or merge it at: > > https://github.com/edicl/hunchentoot/pull/52 > Commit Summary > > - Introduce start-thread as an entry point so specialized taskmasters > > File Changes > > - *M* packages.lisp<https://github.com/edicl/hunchentoot/pull/52/files#diff-0>(2) > - *M* taskmaster.lisp<https://github.com/edicl/hunchentoot/pull/52/files#diff-1>(111) > > Patch Links: > > - https://github.com/edicl/hunchentoot/pull/52.patch > - https://github.com/edicl/hunchentoot/pull/52.diff > >

1 0

[hunchentoot-devel] spawning threads
by Faré 21 Mar '13

21 Mar '13

In quux-hunchentoot, I introduce a gf (defgeneric start-thread (context thunk &key)) with a method (defmethod start-thread ((taskmaster thread-pooling-taskmaster) thunk &key name) (declare (ignorable taskmaster)) (bt:make-thread thunk :name name)) that offers an extension point so that applications can specify bindings, handlers, etc., around the spawning of threads. I believe this technique could be advantageously adopted by hunchentoot in general. PS: if this reminds you of "interface-passing style", that's not a coincidence. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org You may call yourself athiest, but I'm athier than you are!

1 1

[hunchentoot-devel] Race condition in stop
by Faré 17 Mar '13

17 Mar '13

When we stop an acceptor, we set the stop flag then shutdown the taskmaster. But the acceptor will only stop accepting after timeout and/or after the next connection; in the latter case, said connection will find itself without a taskmaster to process it, and will be dropped on the floor without being processed, while possibly leaking a file descriptor, meanwhile the user on the other end waits 5 minutes for a TCP timeout. That's not very nice, especially if stop is a normal part of frequent server rollouts. To make things better, we could do one or both of these: 1- have the acceptor call the shutdown on the taskmaster after it catches its last request (or lack thereof). 2- have the acceptor use select or poll, so it can be notified of the stop in a timely fashion. Would you accept a patch that does one or the other? What libraries are or aren't OK to pull into hunchentoot to achieve the second? [I suppose, any library that doesn't require linking a .so wrapper.] —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The hacker: someone who figured things out and made something cool happen. — Alan Schmitt

2 3

[hunchentoot-devel] If you ever wanted to access multiple uploaded files...
by Hans Hübner 06 Mar '13

06 Mar '13

See this Stackoverflow thread if you wonder how to access them: http://stackoverflow.com/questions/15249921/how-to-handle-multiple-file-upl… -Hans

1 0

[hunchentoot-devel] Reload in browser seems not to work right
by Willem Rein Oudshoorn 03 Mar '13

03 Mar '13

I have some issues when I try to reload a page which is served by hunchentoot. Note that this only happens with Safari. Firefox and Chrome seem to behave correctly. I first observed an issue with weblocks and afterwards I tried plain hunchentoot. The plain hunchentoot exhibits different behaviour, but also a behaviour which seems wrong. 1. Plain hunchentoot -------------------- I did the following with both SBCL and CCL on MacOSX: - start Common Lisp - do: (ql:quickload "hunchentoot") - do: (hunchentoot:start (make-instance 'hunchentoot:easy-acceptor :port 4242)) which is copied from the documantation. - Point my browser to http://localhost:4242 - Observation 1: Everything looks fine - do: Reload in browser - Observation 2: The 'made with lisp image' is not visible anymore. Now it seems an additional reload brings the image back. In fact, reload in the browser toggles the visibility of the image. The developer console of safari seems to indicate that 1/2 the times the request image never arrives. 2. Weblocks ----------- Now this might be a problem with weblocks or hunchentoot, howver the following happens: - A reload takes about 2.7 minutes (the original page is loaded almost instantaneous. - For all my static resources (e.g. javascript files etc), the requests take about 25 seconds and return status 304 which is: +http-not-modified+ - I have 11 static resources (it seems to be doing about 2 requests in parallel??) Has anybody seen something similar? 3. Versions ----------- Hunchentoot: 1.2.11 SBCL: "1.1.3.8-3eed775" CCL: "Version 1.8-r15416M (DarwinX8664)" Safari: Version 6.0.2 (8536.26.17) Kind regards, Wim Oudshoorn.

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

tbnl-devel March 2013