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

Re: Session identity vanishing
by Edi Weitz 08 Apr '15

08 Apr '15

Did you try to set *use-remote-addr-for-sessions* and/or *use-user-agent-for-sessions* to NIL? Cheers, Edi. On Sun, Oct 27, 2013 at 5:44 PM, peter <p2.edoc(a)gmail.com> wrote: > Using Hunchentoot 1.2.7 on Clozure 1.9-r15808 > I get cookies OK when serving HTML from any host I've tried. > Serving JSON on Mac (DarwinX8664) works OK too. > But I lose the cookie (session identity) when serving JSON on EC2 > (linuxx8664). > I expect the deficiency is in my code, but am foxed. > Any suggestions? >

2 1

test
by Anton Vodonosov 08 Apr '15

08 Apr '15

Testing if the list exists, in response to this question on comp.lang.list Christoph-Simon Senjak: > Hi all. > > I just went over http://weitz.de/hunchentoot/#mail and the list that is > linked there is a dead link. I could not find the mailing list anywhere > else. Does it still exist? > > Best regards > CSS

3 2

Re: hunchentoot serving manifest files, ie. .appcache files.
by Ron Garret 08 Apr '15

08 Apr '15

On Mar 1, 2014, at 2:01 PM, Ben Hyde <bhyde(a)pobox.com> wrote: > On Mar 1, 2014, at 3:04 PM, Ron Garret <ron(a)flownet.com> wrote: >> server-side events > > I assume, you cobbled together your own Hunchentoot compatible implementation? Or, is there one kicking about I've not noticed? - ben Here’s a self-contained SSE demo: (require :hunchentoot) (rename-package :hunchentoot :hunchentoot '(:tbnl :ht)) (defvar $server (make-instance 'ht::easy-acceptor :port 1234 :access-log-destination nil)) (ht:start $server) (ht:define-easy-handler (sse-test :uri "/sse-test") () "<script> var source=new EventSource('sse-stream'); source.onmessage=function(event) { document.getElementById('result').innerHTML=event.data + '<br>'; }; </script> Server-side event demo<br> <div id=result></div> ") (defun set-header (name value) (setf (ht:header-out name) value)) (ht:define-easy-handler (sse-stream :uri "/sse-stream") () (set-header "content-type" "text/event-stream") (set-header "cache-control" "no-cache") (let ((stream (ht:send-headers))) (dotimes (i 10) (write-sequence (encode-string-to-octets (format nil "data: test ~A~A~A" i #\newline #\newline)) stream) (force-output stream) (sleep 0.5))))

1 0

Another session problem
by Nicolas Neuss 08 Apr '15

08 Apr '15

Hello, I have the following problem. Hunchentoot 1.2.26/SBCL 1.0.57 is serving pages from behind Apache. More precisely, my Apache config is <VirtualHost *:80> ServerAdmin neuss(a)scipolis.de ServerName yyy.math.fau.de ServerAlias yyy.math.fau.de DocumentRoot /var/www <Directory /> Options FollowSymLinks AllowOverride None </Directory> <Directory /var/www/> Options FollowSymLinks MultiViews AllowOverride None Order allow,deny allow from all </Directory> ErrorLog ${APACHE_LOG_DIR}/error.log ErrorDocument 404 /index.html ProxyRequests Off ProxyPass /wissen http://localhost:8002 ProxyPassReverse /wissen http://localhost:8002 </VirtualHost> Now when accessing the page <http://yyy.math.fau.de/wissen/admin-login?nr=4> for the first time (!), the "form" gets an additional "action" parameter which is an absolute path like <form method=post action='/admin-login?nr=4&hunchentoot-session=17997%3A98C123D51D88E2BDBD28DC2E00D16E42'> while "href"s are (correctly) relative like <a href='about?hunchentoot-session=17997%3A98C123D51D88E2BDBD28DC2E00D16E42'>Informationen</a> This leads to a wrong redirection when submitting the form. Is this a bug or is anything wrong with my setup? I'm using Hunchentoot 1.2.26 from Quicklisp. Thank you, Nicolas P.S.: If one refreshes the page after first access the action parameter goes away and everything works as desired. Also with redirecting to the login page I can remove this behaviour, but I would like to understand what is going on here.

3 10

hunchentoot serving manifest files, ie. .appcache files.
by Faruk S. Can 08 Apr '15

08 Apr '15

how to serve manifest files, ie. .appcache files wit hunchentoot? (mime-type #p"path/to/anifest/file") >nil nil is there a way to do? or is it jsut enough to proxy with apache or nginx front and configure those to serve manifest files, as it is noted in w3schools html5- appcache topic? before i try myself, just asked to bring it to attention for possible renewing improvements to the hunchentoot.

3 2

Re: A bug in functon parse-content-type.
by Jingtaqo Xu 08 Apr '15

08 Apr '15

Hi Hans, The whole thing I want is a a stable hunchentoot server which will be compatible with other web clients and a stable drakma client which will be be compatible with other web servers,whether the web clients/servers follows http protocols well or not should not be the reason which makes hunchentoot/drakma failed directly. I hope you can understand that if drakma/hunchentoot failed directly, my commercial business will fail too. I must say that the codes from Edi has very high qulities,and I have high respect to Edi and you for that. For the case of this question, I hope chunga/drakma/hunchentoot could accept a special feature or a speical variable to make them accept the content type header which not follows http protocols well,like cl-http does. ----------------------------------------------------------------------------- (parse-mime-content-type-header "application/x-www-form-urlencoded; text/html; charset=UTF-8") ==> (:APPLICATION :X-WWW-FORM-URLENCODED :CHARSET :UTF-8) ----------------------------------------------------------------------------- I think your solution(request-with-bad-content-type) will be a little trivial for me. If you accept my suggestion, I can give you a patch for these three packages(chunga/drakma/hunchentoot). With Best Regards, At Sun, 26 May 2013 08:04:15 +0200, Hans Hübner wrote: > > [1 <text/plain; ISO-8859-1 (quoted-printable)>] > > [2 <text/html; ISO-8859-1 (quoted-printable)>] > Jingtao, > > please refer to http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.7, it clearly > describes that a media type consists of exactly one type/subtype indicator followed by > optional attribute=value pairs. The content type that you have presented is not valid > according to these rules. Neither a lax parser like the one in CL-HTTP nor the fact > that a large site sends these bogus headers makes them valid. I do not want to include > code in Hunchentoot that tries to interpret such bogus data. > > However, if you cannot get your trading partner to fix their client, I can offer this > solution: > > (defclass request-with-bad-content-type (hunchentoot:request) > ()) > > (defmethod hunchentoot:header-in :around ((name (eql :content-type)) (request > request-with-bad-content-type)) > (alexandria:when-let (content-type (call-next-method)) > (ppcre:regex-replace-all "^([^/]+/[^/]+); *[^/]+/[^/;]+" content-type "\\1"))) > > You'll then have to use the :request-class argument to your acceptor instantiation to > make it use the request-with-bad-content-type class. You also want to review the regular > expression carefully and maybe profile your application to see whether you need to cache > or otherwise improve performance. > > -Hans > > On Sun, May 26, 2013 at 5:07 AM, Jingtao Xu <jingtaozf(a)gmail.com> wrote: > > Hi Hans, > > I don't agree with you to say that this content type header is just bogus. > As the content-type is sent by the largest B2B/B2C site in china, it > must have a reason. > > And if you try cl-http, you can find that cl-http will parse such > content type correctly. > > ----------------------------------------------------------------------------- > (parse-mime-content-type-header "application/x-www-form-urlencoded; > text/html; charset=UTF-8") > ==> (:APPLICATION :X-WWW-FORM-URLENCODED :CHARSET :UTF-8) > ----------------------------------------------------------------------------- > > You can find the definition in cl-http/server/headers.lisp > ----------------------------------------------------------------------------- > (define-header-type :content-type-header (:header) > :parse-function parse-mime-content-type-header > :print-function print-mime-content-type-header) > ----------------------------------------------------------------------------- > > Even this content-type header is bogus(actually I don't think so), > hunchentoot/drakma should parse > the header without raising an error if one special variable like * > accept-bogus-content-type* is true. > > With Best Regards, > jingtao. > > On Sat, May 25, 2013 at 8:11 PM, Hans Hübner <hans.huebner(a)gmail.com> wrote: > > Jingtao, > > > > the content-type header "application/x-www-form-urlencoded; text/html; > > charset=UTF-8" is just bogus. I do not want to include code that makes > > Hunchentoot work with clearly broken clients. Better error reporting would > > be acceptable, though. > > > > -Hans > > > > > > On Sat, May 25, 2013 at 12:38 PM, Jingtao Xu <jingtaozf(a)gmail.com> wrote: > >> > >> Hi all, > >> > >> I found the content type header which raise the bug in my message.log > >> generated by hunchentoot. > >> It happened when hunchentoot get following content type header: > >> > >> > >> > ----------------------------------------------------------------------------------------- > >> application/x-www-form-urlencoded; text/html; charset=UTF-8 > >> > >> > ----------------------------------------------------------------------------------------- > >> > >> I noticed that in package drakma's file read.lisp,function > >> 'get-content-type' > >> also assumed "/" as a token separator. > >> > >> I hope package chunga/drakma/hunchentoot could accept such content type > >> header > >> without raising an exception,As Edl said,a new special variable > >> similar to *accept-bogus-eols* or > >> *treat-semicolon-as-continuation* which only assume " ,;" as token > >> separator may be a good idea and will fix my question. > >> > >> Any way, RFC standard is not well fit with the read world. > >> > >> Thanks very much. > >> > >> WIth Best Regards, > >> jingtao. > >> > >> > >> On Thu, May 23, 2013 at 2:01 PM, Edi Weitz <edi(a)agharta.de> wrote: > >> > I'm not the maintainer anymore, but my take is that if some Ruby or > >> > Java client misinterprets the RFC I wouldn't change Hunchentoot's (or > >> > rather Chunga's) default behavior because of that. I'd rather > >> > introduce a new special variable similar to *accept-bogus-eols* or > >> > *treat-semicolon-as-continuation*. > >> > > >> > Just my .02 Euros, > >> > Edi. > >> > > >> > > >> > > >> > On Thu, May 23, 2013 at 2:52 AM, Jingtao Xu <jingtaozf(a)gmail.com> wrote: > >> >> Hi All, > >> >> > >> >> 1. The function `read-name-value-pair' is called by ` > >> >> parse-content-type' in hunchentoo/util.lisp,not by my codes. > >> >> 2. the slash is a token constituent in java/ruby implementation,and I > >> >> think some web client/server treat it as a token constituent too, > >> >> but I am waiting for the hunchentoot log to give us a live example. > >> >> > >> >> With Best Regards, > >> >> jingtao > >> >> > >> >> > >> >> On Wed, May 22, 2013 at 11:40 PM, Edi Weitz <edi(a)agharta.de> wrote: > >> >>> If I'm not mistaken, the slash is a "separator" and thus not a token > >> >>> constituent according to RFC 2616 which means "path=/foo" is not legal > >> >>> input for READ-NAME-VALUE-PAIR. > >> >>> > >> >>> On Wed, May 22, 2013 at 5:27 PM, Ron Garret <ron(a)flownet.com> wrote: > >> >>>> Very likely Jingtao's code is calling READ-NAME-VALUE-PAIR without > >> >>>> being wrapped in this macro > >> >>>> > >> >>>> But there's still a bug in READ-NAME-VALUE-PAIR: > >> >>>> > >> >>>> ? (WITH-INPUT-FROM-VECTOR (S (MAP '(VECTOR (UNSIGNED-BYTE 8)) > >> >>>> 'CHAR-CODE "path=/foo")) > >> >>>> (chunga:with-character-stream-semantics > >> >>>> (CHUNGA:READ-NAME-VALUE-PAIR S))) > >> >>>> ("path" . "") > >> >>>> > >> >>>> On May 22, 2013, at 8:19 AM, Edi Weitz wrote: > >> >>>> > >> >>>>> On Wed, May 22, 2013 at 4:18 PM, Ron Garret <ron(a)flownet.com> wrote: > >> >>>>>> I found a bug in CHUNGA:READ-NAME-VALUE-PAIR. > >> >>>>> > >> >>>>> It's not quite clear to me yet what the bug is supposed to be. > >> >>>>> > >> >>>>> The documentation clearly says that calls to READ-NAME-VALUE-PAIR > >> >>>>> and > >> >>>>> friends must be wrapped with this macro: > >> >>>>> > >> >>>>> http://weitz.de/chunga/#with-character-stream-semantics > >> >>>>> > >> >>>>> (You might argue that this isn't very user-friendly, but Chunga > >> >>>>> wasn't > >> >>>>> really intended to be used that way.) > >> >>>> > >> >> > > > > > >

6 19

Fw: ssl support
by José Ronquillo 08 Apr '15

08 Apr '15

Hello Hans, my setup is common lisp implementation: SBCL 1.1.14 Linux 3.10.5 i686 and Linux 3.10 amd64 Hunchentoot version 1.2.24 This code can help you to reproduce the problem: (ql:quickload "hunchentoot") (defvar *acceptor* nil "El acceptor de hunchentoot") (defun inicia-ht (&optional (port 4242)) (format t "Iniciando el servidor en el puerto ~5,'0d~%" port) (setf *acceptor* (make-instance 'hunchentoot:easy-ssl-acceptor :port port :ssl-certificate-file "./server.crt" :ssl-privatekey-file "./server.key")) ; (setf *acceptor* (make-instance 'hunchentoot:easy-acceptor ; :port port) (setf (hunchentoot:acceptor-document-root *acceptor*) (pathname "/var/www/")) (hunchentoot:start *acceptor*)) (inicia-ht) You can test with ab with and without ssl ab -n 1000 -c 10 https://localhost:4242/index.html ab -n 1000 -c 10 http://localhost:4242/index.html

3 2

sessions
by Faruk S. Can 08 Apr '15

08 Apr '15

hi i cannot sustain a session. i login to my app. it shows my login name as i programmed. when i refresh the page it stays there. but when i refresh for the second time my session name and other things goes away and instead i see what is there for the not loginned case. I think i miss something in hunchentoot session hadling. ;all html generated by a macro: (defmacro ff (tag) `(defun ,tag (&rest c) (with-output-to-string (*standard-output*) (format t "<~a ~{~a='~a' ~}> ~{~a ~}</~a>" ',tag (car c) (cdr c) ',tag)))) ;;defining all tag functions: (progn (ff html) (ff title) (ff head) (ff meta) (ff link) (ff style) (ff script) (ff body) (ff span) (ff div) (ff section) (ff p) (ff form) (ff input) (ff button) (ff textarea) (ff a) (ff h1) (ff h2) (ff h3) (ff h4) (ff h5) (ff h6) (ff ol) (ff ul) (ff li)) ;authentication utilities used by the home page function at the bottom: (defun signed-in-p () (if (and (boundp '*session*) (session-value '*signed-in *session*)) t nil)) (defun signed-up-p (x y) (if (with-connection *conn1spec* (query (:select 'username 'password :from 'users.users :where (:and (:= 'username x) (:= 'password y))))) t nil)) (defun sign-in () (let ((username (parameter "username")) (password (parameter "password"))) (if (signed-up-p username password) (progn (start-session) (setf (session-value '*username) username) (setf (session-value '*signed-in) t) (morph-status-plate (session-value '*username))) (with-output-to-string (s) (princ (morph-sign-in-form) s) (princ "No record found!" s) (princ (a (list :href "/form-sign-up") "Sign up") s) )))) ;the data base querying functions are working correctly ;views generated: (defun morph-write-button () (div (list :style "border:1px solid; float:left;") (a (list :href "/writingp") "write"))) (defun morph-status-plate (username) (div (list :id "status-plate" :style "border:1px solid; float:left;") (span () "123 users online") (span () username) (button (list :onclick "ajaxlogout()") "logout"))) (defun morph-sign-in-form () (div (list :id "sign-in-form" :style "border:1px solid; float:left;") (form (list :method "" :action "") (input (list :id "username" :type "input" :name "username")) (input (list :id "password" :type "input" :name "password")) (input (list :onClick "ajaxsignin()" :type "button" :value "login"))))) ;at last ;the page i generate as home page: (div (list :id "sign-in-form-or-status-plate" :style "height: 45px; border: 1px solid; float:left;") (if (signed-in-p);;;;;; (with-output-to-string (s) (start-session) (princ (morph-status-plate (session-value '*username)) s) (princ (morph-write-button) s)) (with-output-to-string (s) (princ (morph-sign-in-form) s) (princ (a (list :href "form-sign-up") "Sign up") s))))

1 3

Re: hunchentoot serving manifest files, ie. .appcache files.
by Faruk S. Can 08 Apr '15

08 Apr '15

I have another question about hunchentoot. Is it possible to use server sent events with hunchentoot, like other html5 improvements mentioned in w3schools-html5 such as app cache, local storage, session storage? as that one related to and depend on the server side support.

4 10

ssl support
by José Ronquillo 08 Apr '15

08 Apr '15

I am currently writing a web application using Hunchentoot; but it seems that there is a problem with its ssl support (using easy-ssl-acceptor): for some unknow reason for me, sbcl, the commom lisp implementation that I use, grows its memory whitout limit when I make tests with ab. I have tested with hunchentoot:easy-acceptor and this problem with the memory does not occur. Does anyone of you guys had seen this behavior?

2 1