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

(no subject)
by Faruk S. Can 08 Apr '15

08 Apr '15

maybe comic enough but i cannot serve an html file that is linked to css file. test.html <html> <head> <link rel="stylesheet" type="text/css" href="~/mystyle.css"> </head> <body> asdf </body> </html> mystyle.css body { background-color:tan; } this html is rendered when i double click it. but i cannot serve it with style aded. alt console says: 127.0.0.1 - [2014-03-09 22:09:46] "GET /test HTTP/1.1" 200 114 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_2) AppleWebKit/537.74.9 (KHTML, like Gecko) Version/7.0.2 Safari/537.74.9" 127.0.0.1 - [2014-03-09 22:09:46] "GET /~/mystyle.css HTTP/1.1" 404 360 " http://localhost:5050/test" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_2) AppleWebKit/537.74.9 (KHTML, like Gecko) Version/7.0.2 Safari/537.74.9" What should i do?

1 0

easy-handlers: contrary to the docs, integer parameters are parsed with :junk-allowed t
by Anton Vodonosov 08 Apr '15

08 Apr '15

Reading the doc here http://weitz.de/hunchentoot/#easy-handlers > If parameter-type is 'INTEGER and the parameter string consists solely > of decimal digits, var's value will be the corresponding integer, otherwise NIL. But when I enter "50jj99" to the form, the parameter gets value 50. The doc and implementation disagree. Best regards, - Anton

1 0

Missing client-as-string for Lispworks
by Raymond Wiker 08 Apr '15

08 Apr '15

I see that there is a recent change that means that client-as-string is called from create-request- handler-thread. This breaks for Lispworks users, as client-as-string is only defined for platforms that use usocket (or strictly speaking, for platforms which are not lispworks :-) The following implementation of client-as-string seems to do what's required for Lispworks: #+:lispworks (defun client-as-string (socket) "A helper function which returns the client's address and port as a string and tries to act robustly in the presence of network problems." (multiple-value-bind (address port) (comm:get-socket-peer-address socket) (when (and address port) (format nil "~A:~A" (comm:ip-address-string address) port))))

1 0

serving html linked to css or js files
by Faruk S. Can 08 Apr '15

08 Apr '15

maybe comic enough but i cannot serve an html file that is linked to css file. test.html <html> <head> <link rel="stylesheet" type="text/css" href="~/mystyle.css"> </head> <body> asdf </body> </html> mystyle.css body { background-color:tan; } this html is rendered when i double click it. but i cannot serve it with style aded. alt console says: 127.0.0.1 - [2014-03-09 22:09:46] "GET /test HTTP/1.1" 200 114 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_2) AppleWebKit/537.74.9 (KHTML, like Gecko) Version/7.0.2 Safari/537.74.9" 127.0.0.1 - [2014-03-09 22:09:46] "GET /~/mystyle.css HTTP/1.1" 404 360 " http://localhost:5050/test" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_2) AppleWebKit/537.74.9 (KHTML, like Gecko) Version/7.0.2 Safari/537.74.9" What should i do?

1 0

Re: Persistent sessions
by peter 08 Apr '15

08 Apr '15

Given that the cookie is the product of md5-hexing the raw composite cookie data (in encode-session-string), there's no way to get the initial click (creation) time of the session (which is needed in order to ascertain whether the session has expired (session-too-old-p)). So presumably, like the session-ID, we'll need to carry the session start time externally (outside the md5-hexed part of the cookie). Are we thinking along the same rg? I'm puzzled that session persistence isn't a common requirement of hunchentoot. -peter

2 1

[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