From lispercat at gmail.com Tue Jul 10 22:04:52 2012 From: lispercat at gmail.com (Andrei Stebakov) Date: Tue, 10 Jul 2012 18:04:52 -0400 Subject: [hunchentoot-devel] Calculating size of the uploaded file Message-ID: Hi It's been discussed before (even prior Hunchentoot 1.0.0) that there has to be some way to allow the developer to calculate size of the file being uploaded and act upon that (maybe cancel the upload if the file is too big). Before I did it using a hack into parse-multipart-form-data function where I provided a callback to my own function which calculated the size of (header-in :content-length request) and if it was too big, aborted the request. I wonder if there is a better way to do it with the new architecture? Also if I put my own hacks into the ht code it would be difficult for me to update. Thank you, Andrei From hans.huebner at gmail.com Wed Jul 11 04:40:46 2012 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Wed, 11 Jul 2012 06:40:46 +0200 Subject: [hunchentoot-devel] Calculating size of the uploaded file In-Reply-To: References: Message-ID: Andrei, there are no specific hooks in the code that report the file size of uploaded files, but the situation has changed compared to 2008 in that we do no longer intend to replace the rfc2388 library in the foreseeable future. There are some pending changes regarding how uploaded files are handled which have not been merged because we're waiting for rfc2388 to be updated in Quicklisp. Maybe these changes help you, too: https://github.com/fighting-spirit/hunchentoot/commit/301db3d6f6291dd8690b095ee708fff2d53f5664 If you have any suggestions in form of a patch based on these changes that would help you get your problem solved, please let us know. -Hans On Wed, Jul 11, 2012 at 12:04 AM, Andrei Stebakov wrote: > Hi > > It's been discussed before (even prior Hunchentoot 1.0.0) that there > has to be some way to allow the developer to calculate size of the > file being uploaded and act upon that (maybe cancel the upload if the > file is too big). > Before I did it using a hack into parse-multipart-form-data function > where I provided a callback to my own function which calculated the > size of (header-in :content-length request) and if it was too big, > aborted the request. > I wonder if there is a better way to do it with the new architecture? > Also if I put my own hacks into the ht code it would be difficult for > me to update. > > Thank you, > Andrei > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel From lispercat at gmail.com Sat Jul 14 04:24:25 2012 From: lispercat at gmail.com (Andrei Stebakov) Date: Sat, 14 Jul 2012 00:24:25 -0400 Subject: [hunchentoot-devel] *show-lisp-errors-p* ignored? Message-ID: Hi I got following variables set before running Hunchentoot (setf hunchentoot:*catch-errors-p* t) (setf hunchentoot:*show-lisp-errors-p* nil) (setf hunchentoot:*log-lisp-errors-p* t) (setf hunchentoot:*show-lisp-backtraces-p* nil) For some reason, when an error happens (or when I explicitly call (error "test")), I still see the whole lisp backtrace printed in the browser. How do I fix this? It looks like make-cooked-message isn't called for every request as well. Thank you, Andrei From hans.huebner at gmail.com Sat Jul 14 06:20:50 2012 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Sat, 14 Jul 2012 08:20:50 +0200 Subject: [hunchentoot-devel] *show-lisp-errors-p* ignored? In-Reply-To: References: Message-ID: Andrei, the *show-lisp-errors-p* and *show-lisp-backtraces-p* are ignored if the acceptor has been instantiated with an error template directory, which is the default. You need to use :error-template-directory nil when instantiating the acceptor to use the cooked messaging feature, which looks at these variable settings. http://weitz.de/hunchentoot/#*show-lisp-errors-p* -Hans On Sat, Jul 14, 2012 at 6:24 AM, Andrei Stebakov wrote: > Hi > > I got following variables set before running Hunchentoot > > (setf hunchentoot:*catch-errors-p* t) > (setf hunchentoot:*show-lisp-errors-p* nil) > (setf hunchentoot:*log-lisp-errors-p* t) > (setf hunchentoot:*show-lisp-backtraces-p* nil) > > For some reason, when an error happens (or when I explicitly call > (error "test")), I still see the whole lisp backtrace printed in the > browser. > How do I fix this? It looks like make-cooked-message isn't called for > every request as well. > > Thank you, > Andrei > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel From lispercat at gmail.com Mon Jul 23 20:08:41 2012 From: lispercat at gmail.com (Andrei Stebakov) Date: Mon, 23 Jul 2012 16:08:41 -0400 Subject: [hunchentoot-devel] *show-lisp-errors-p* ignored? In-Reply-To: References: Message-ID: Thank you, Hans for the prompt response. On the related subject, it used to be *http-error-handler* variable that I set to a function where I handled all errors related to my own run-time environment, (not hunchentoot related). Basically before, I saved the error message in the hunchentoot session-value and triggered (error ...) function. My handler specified by *http-error-handler* would be called so I generated an error page printing the saved message from the session-value. Now that the *http-error-handler* variable has been deprecated, what is the best place I could put my own error page generation code? Thank you, Andrei On Sat, Jul 14, 2012 at 2:20 AM, Hans H?bner wrote: > Andrei, > > the *show-lisp-errors-p* and *show-lisp-backtraces-p* are ignored if > the acceptor has been instantiated with an error template directory, > which is the default. You need to use :error-template-directory nil > when instantiating the acceptor to use the cooked messaging feature, > which looks at these variable settings. > > http://weitz.de/hunchentoot/#*show-lisp-errors-p* > > -Hans > > On Sat, Jul 14, 2012 at 6:24 AM, Andrei Stebakov wrote: >> Hi >> >> I got following variables set before running Hunchentoot >> >> (setf hunchentoot:*catch-errors-p* t) >> (setf hunchentoot:*show-lisp-errors-p* nil) >> (setf hunchentoot:*log-lisp-errors-p* t) >> (setf hunchentoot:*show-lisp-backtraces-p* nil) >> >> For some reason, when an error happens (or when I explicitly call >> (error "test")), I still see the whole lisp backtrace printed in the >> browser. >> How do I fix this? It looks like make-cooked-message isn't called for >> every request as well. >> >> Thank you, >> Andrei >> >> _______________________________________________ >> tbnl-devel site list >> tbnl-devel at common-lisp.net >> http://common-lisp.net/mailman/listinfo/tbnl-devel > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel From hans.huebner at gmail.com Mon Jul 23 20:19:43 2012 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Mon, 23 Jul 2012 22:19:43 +0200 Subject: [hunchentoot-devel] *show-lisp-errors-p* ignored? In-Reply-To: References: Message-ID: Andrei, you can implement a method for HUNCHENTOOT:ACCEPTOR-STATUS-MESSAGE (http://weitz.de/hunchentoot/#acceptor-status-message) specialized for your own acceptor class if the cooked message and the templating mechanism are insufficient for your needs. -Hans On Mon, Jul 23, 2012 at 10:08 PM, Andrei Stebakov wrote: > Thank you, Hans for the prompt response. > On the related subject, it used to be *http-error-handler* variable > that I set to a function where I handled all errors related to my own > run-time environment, (not hunchentoot related). > Basically before, I saved the error message in the hunchentoot > session-value and triggered (error ...) function. > My handler specified by *http-error-handler* would be called so I > generated an error page printing the saved message from the > session-value. > Now that the *http-error-handler* variable has been deprecated, what > is the best place I could put my own error page generation code? > > Thank you, > Andrei > > On Sat, Jul 14, 2012 at 2:20 AM, Hans H?bner wrote: >> Andrei, >> >> the *show-lisp-errors-p* and *show-lisp-backtraces-p* are ignored if >> the acceptor has been instantiated with an error template directory, >> which is the default. You need to use :error-template-directory nil >> when instantiating the acceptor to use the cooked messaging feature, >> which looks at these variable settings. >> >> http://weitz.de/hunchentoot/#*show-lisp-errors-p* >> >> -Hans >> >> On Sat, Jul 14, 2012 at 6:24 AM, Andrei Stebakov wrote: >>> Hi >>> >>> I got following variables set before running Hunchentoot >>> >>> (setf hunchentoot:*catch-errors-p* t) >>> (setf hunchentoot:*show-lisp-errors-p* nil) >>> (setf hunchentoot:*log-lisp-errors-p* t) >>> (setf hunchentoot:*show-lisp-backtraces-p* nil) >>> >>> For some reason, when an error happens (or when I explicitly call >>> (error "test")), I still see the whole lisp backtrace printed in the >>> browser. >>> How do I fix this? It looks like make-cooked-message isn't called for >>> every request as well. >>> >>> Thank you, >>> Andrei >>> >>> _______________________________________________ >>> tbnl-devel site list >>> tbnl-devel at common-lisp.net >>> http://common-lisp.net/mailman/listinfo/tbnl-devel >> >> _______________________________________________ >> tbnl-devel site list >> tbnl-devel at common-lisp.net >> http://common-lisp.net/mailman/listinfo/tbnl-devel > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel From lispercat at gmail.com Tue Jul 24 14:31:40 2012 From: lispercat at gmail.com (Andrei Stebakov) Date: Tue, 24 Jul 2012 10:31:40 -0400 Subject: [hunchentoot-devel] *show-lisp-errors-p* ignored? In-Reply-To: References: Message-ID: As I understand the whole acceptor-status-message has to be overloaded? The user is discourage from defining their own (def-http-return-code +some-user-code+ 777 "Some user message")? Andrei On Mon, Jul 23, 2012 at 4:19 PM, Hans H?bner wrote: > Andrei, > > you can implement a method for HUNCHENTOOT:ACCEPTOR-STATUS-MESSAGE > (http://weitz.de/hunchentoot/#acceptor-status-message) specialized for > your own acceptor class if the cooked message and the templating > mechanism are insufficient for your needs. > > -Hans > > On Mon, Jul 23, 2012 at 10:08 PM, Andrei Stebakov wrote: >> Thank you, Hans for the prompt response. >> On the related subject, it used to be *http-error-handler* variable >> that I set to a function where I handled all errors related to my own >> run-time environment, (not hunchentoot related). >> Basically before, I saved the error message in the hunchentoot >> session-value and triggered (error ...) function. >> My handler specified by *http-error-handler* would be called so I >> generated an error page printing the saved message from the >> session-value. >> Now that the *http-error-handler* variable has been deprecated, what >> is the best place I could put my own error page generation code? >> >> Thank you, >> Andrei >> >> On Sat, Jul 14, 2012 at 2:20 AM, Hans H?bner wrote: >>> Andrei, >>> >>> the *show-lisp-errors-p* and *show-lisp-backtraces-p* are ignored if >>> the acceptor has been instantiated with an error template directory, >>> which is the default. You need to use :error-template-directory nil >>> when instantiating the acceptor to use the cooked messaging feature, >>> which looks at these variable settings. >>> >>> http://weitz.de/hunchentoot/#*show-lisp-errors-p* >>> >>> -Hans >>> >>> On Sat, Jul 14, 2012 at 6:24 AM, Andrei Stebakov wrote: >>>> Hi >>>> >>>> I got following variables set before running Hunchentoot >>>> >>>> (setf hunchentoot:*catch-errors-p* t) >>>> (setf hunchentoot:*show-lisp-errors-p* nil) >>>> (setf hunchentoot:*log-lisp-errors-p* t) >>>> (setf hunchentoot:*show-lisp-backtraces-p* nil) >>>> >>>> For some reason, when an error happens (or when I explicitly call >>>> (error "test")), I still see the whole lisp backtrace printed in the >>>> browser. >>>> How do I fix this? It looks like make-cooked-message isn't called for >>>> every request as well. >>>> >>>> Thank you, >>>> Andrei >>>> >>>> _______________________________________________ >>>> tbnl-devel site list >>>> tbnl-devel at common-lisp.net >>>> http://common-lisp.net/mailman/listinfo/tbnl-devel >>> >>> _______________________________________________ >>> tbnl-devel site list >>> tbnl-devel at common-lisp.net >>> http://common-lisp.net/mailman/listinfo/tbnl-devel >> >> _______________________________________________ >> tbnl-devel site list >> tbnl-devel at common-lisp.net >> http://common-lisp.net/mailman/listinfo/tbnl-devel > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel From hans.huebner at gmail.com Tue Jul 24 15:41:16 2012 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Tue, 24 Jul 2012 17:41:16 +0200 Subject: [hunchentoot-devel] *show-lisp-errors-p* ignored? In-Reply-To: References: Message-ID: Andrei, you are welcome to send patches if you feel that Hunchentoot lacks functionality that you need. Please use github pull requests. Do not forget to include documentation updates if you want to change the public API. Thanks, Hans Am 24.07.2012 16:32 schrieb "Andrei Stebakov" : > As I understand the whole acceptor-status-message has to be overloaded? > The user is discourage from defining their own (def-http-return-code > +some-user-code+ 777 "Some user message")? > > Andrei > > On Mon, Jul 23, 2012 at 4:19 PM, Hans H?bner > wrote: > > Andrei, > > > > you can implement a method for HUNCHENTOOT:ACCEPTOR-STATUS-MESSAGE > > (http://weitz.de/hunchentoot/#acceptor-status-message) specialized for > > your own acceptor class if the cooked message and the templating > > mechanism are insufficient for your needs. > > > > -Hans > > > > On Mon, Jul 23, 2012 at 10:08 PM, Andrei Stebakov > wrote: > >> Thank you, Hans for the prompt response. > >> On the related subject, it used to be *http-error-handler* variable > >> that I set to a function where I handled all errors related to my own > >> run-time environment, (not hunchentoot related). > >> Basically before, I saved the error message in the hunchentoot > >> session-value and triggered (error ...) function. > >> My handler specified by *http-error-handler* would be called so I > >> generated an error page printing the saved message from the > >> session-value. > >> Now that the *http-error-handler* variable has been deprecated, what > >> is the best place I could put my own error page generation code? > >> > >> Thank you, > >> Andrei > >> > >> On Sat, Jul 14, 2012 at 2:20 AM, Hans H?bner > wrote: > >>> Andrei, > >>> > >>> the *show-lisp-errors-p* and *show-lisp-backtraces-p* are ignored if > >>> the acceptor has been instantiated with an error template directory, > >>> which is the default. You need to use :error-template-directory nil > >>> when instantiating the acceptor to use the cooked messaging feature, > >>> which looks at these variable settings. > >>> > >>> http://weitz.de/hunchentoot/#*show-lisp-errors-p* > >>> > >>> -Hans > >>> > >>> On Sat, Jul 14, 2012 at 6:24 AM, Andrei Stebakov > wrote: > >>>> Hi > >>>> > >>>> I got following variables set before running Hunchentoot > >>>> > >>>> (setf hunchentoot:*catch-errors-p* t) > >>>> (setf hunchentoot:*show-lisp-errors-p* nil) > >>>> (setf hunchentoot:*log-lisp-errors-p* t) > >>>> (setf hunchentoot:*show-lisp-backtraces-p* nil) > >>>> > >>>> For some reason, when an error happens (or when I explicitly call > >>>> (error "test")), I still see the whole lisp backtrace printed in the > >>>> browser. > >>>> How do I fix this? It looks like make-cooked-message isn't called for > >>>> every request as well. > >>>> > >>>> Thank you, > >>>> Andrei > >>>> > >>>> _______________________________________________ > >>>> tbnl-devel site list > >>>> tbnl-devel at common-lisp.net > >>>> http://common-lisp.net/mailman/listinfo/tbnl-devel > >>> > >>> _______________________________________________ > >>> tbnl-devel site list > >>> tbnl-devel at common-lisp.net > >>> http://common-lisp.net/mailman/listinfo/tbnl-devel > >> > >> _______________________________________________ > >> tbnl-devel site list > >> tbnl-devel at common-lisp.net > >> http://common-lisp.net/mailman/listinfo/tbnl-devel > > > > _______________________________________________ > > tbnl-devel site list > > tbnl-devel at common-lisp.net > > http://common-lisp.net/mailman/listinfo/tbnl-devel > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lispercat at gmail.com Tue Jul 24 18:01:49 2012 From: lispercat at gmail.com (Andrei Stebakov) Date: Tue, 24 Jul 2012 14:01:49 -0400 Subject: [hunchentoot-devel] *show-lisp-errors-p* ignored? In-Reply-To: References: Message-ID: Certainly, I was just wondering about the philosophy of the new error handing mechanism. I thought if it was based on custom http return codes defined by def-http-return-code than the users would define their own using the same mechanism. Thank you, Andrei On Tue, Jul 24, 2012 at 11:41 AM, Hans H?bner wrote: > Andrei, > > you are welcome to send patches if you feel that Hunchentoot lacks > functionality that you need. Please use github pull requests. Do not forget > to include documentation updates if you want to change the public API. > > Thanks, > Hans > > Am 24.07.2012 16:32 schrieb "Andrei Stebakov" : > >> As I understand the whole acceptor-status-message has to be overloaded? >> The user is discourage from defining their own (def-http-return-code >> +some-user-code+ 777 "Some user message")? >> >> Andrei >> >> On Mon, Jul 23, 2012 at 4:19 PM, Hans H?bner >> wrote: >> > Andrei, >> > >> > you can implement a method for HUNCHENTOOT:ACCEPTOR-STATUS-MESSAGE >> > (http://weitz.de/hunchentoot/#acceptor-status-message) specialized for >> > your own acceptor class if the cooked message and the templating >> > mechanism are insufficient for your needs. >> > >> > -Hans >> > >> > On Mon, Jul 23, 2012 at 10:08 PM, Andrei Stebakov >> > wrote: >> >> Thank you, Hans for the prompt response. >> >> On the related subject, it used to be *http-error-handler* variable >> >> that I set to a function where I handled all errors related to my own >> >> run-time environment, (not hunchentoot related). >> >> Basically before, I saved the error message in the hunchentoot >> >> session-value and triggered (error ...) function. >> >> My handler specified by *http-error-handler* would be called so I >> >> generated an error page printing the saved message from the >> >> session-value. >> >> Now that the *http-error-handler* variable has been deprecated, what >> >> is the best place I could put my own error page generation code? >> >> >> >> Thank you, >> >> Andrei >> >> >> >> On Sat, Jul 14, 2012 at 2:20 AM, Hans H?bner >> >> wrote: >> >>> Andrei, >> >>> >> >>> the *show-lisp-errors-p* and *show-lisp-backtraces-p* are ignored if >> >>> the acceptor has been instantiated with an error template directory, >> >>> which is the default. You need to use :error-template-directory nil >> >>> when instantiating the acceptor to use the cooked messaging feature, >> >>> which looks at these variable settings. >> >>> >> >>> http://weitz.de/hunchentoot/#*show-lisp-errors-p* >> >>> >> >>> -Hans >> >>> >> >>> On Sat, Jul 14, 2012 at 6:24 AM, Andrei Stebakov >> >>> wrote: >> >>>> Hi >> >>>> >> >>>> I got following variables set before running Hunchentoot >> >>>> >> >>>> (setf hunchentoot:*catch-errors-p* t) >> >>>> (setf hunchentoot:*show-lisp-errors-p* nil) >> >>>> (setf hunchentoot:*log-lisp-errors-p* t) >> >>>> (setf hunchentoot:*show-lisp-backtraces-p* nil) >> >>>> >> >>>> For some reason, when an error happens (or when I explicitly call >> >>>> (error "test")), I still see the whole lisp backtrace printed in the >> >>>> browser. >> >>>> How do I fix this? It looks like make-cooked-message isn't called for >> >>>> every request as well. >> >>>> >> >>>> Thank you, >> >>>> Andrei >> >>>> >> >>>> _______________________________________________ >> >>>> tbnl-devel site list >> >>>> tbnl-devel at common-lisp.net >> >>>> http://common-lisp.net/mailman/listinfo/tbnl-devel >> >>> >> >>> _______________________________________________ >> >>> tbnl-devel site list >> >>> tbnl-devel at common-lisp.net >> >>> http://common-lisp.net/mailman/listinfo/tbnl-devel >> >> >> >> _______________________________________________ >> >> tbnl-devel site list >> >> tbnl-devel at common-lisp.net >> >> http://common-lisp.net/mailman/listinfo/tbnl-devel >> > >> > _______________________________________________ >> > tbnl-devel site list >> > tbnl-devel at common-lisp.net >> > http://common-lisp.net/mailman/listinfo/tbnl-devel >> >> _______________________________________________ >> tbnl-devel site list >> tbnl-devel at common-lisp.net >> http://common-lisp.net/mailman/listinfo/tbnl-devel > > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel From sebyte at smolny.plus.com Tue Jul 24 18:00:35 2012 From: sebyte at smolny.plus.com (Sebastian Tennant) Date: Tue, 24 Jul 2012 18:00:35 +0000 Subject: [hunchentoot-devel] *show-lisp-errors-p* ignored? References: Message-ID: <394h59a4.fsf@chimera.gnukahvesi.net> Quoth Andrei Stebakov : > As I understand the whole acceptor-status-message has to be overloaded? (use-package :hunchentoot) First you have to subclass acceptor. For example: (defclass custom-acceptor (acceptor) nil) Now you can specialise acceptor-status-message on custom-acceptor like so: (defmethod acceptor-status-message ((acceptor custom-acceptor) http-status-code &rest args &key &allow-other-keys) (when (equal http-status-code +http-internal-server-error+) (apply custom-error-page args)) (call-next-method)) Finally define custom-error-page: (defun custom-error-page (k1 error k2 backtrace) (format nil "

whoops!

Error: ~a

~a " error backtrace)) Don't forget to start your custom-acceptor like so: (tbnl:start (make-instance 'custom-acceptor ...)) Hope this helps. None of this code is tested by the way. Seb -- Emacs' AlsaPlayer - Music Without Jolts Lightweight, full-featured and mindful of your idyllic happiness. http://home.gna.org/eap From lispercat at gmail.com Tue Jul 24 18:33:19 2012 From: lispercat at gmail.com (Andrei Stebakov) Date: Tue, 24 Jul 2012 14:33:19 -0400 Subject: [hunchentoot-devel] *show-lisp-errors-p* ignored? In-Reply-To: <394h59a4.fsf@chimera.gnukahvesi.net> References: <394h59a4.fsf@chimera.gnukahvesi.net> Message-ID: I see now, thanks a lot. Andrew On Tue, Jul 24, 2012 at 2:00 PM, Sebastian Tennant wrote: > Quoth Andrei Stebakov : >> As I understand the whole acceptor-status-message has to be overloaded? > > (use-package :hunchentoot) > > First you have to subclass acceptor. For example: > > (defclass custom-acceptor (acceptor) nil) > > Now you can specialise acceptor-status-message on custom-acceptor like so: > > (defmethod acceptor-status-message > ((acceptor custom-acceptor) http-status-code &rest args &key &allow-other-keys) > (when (equal http-status-code +http-internal-server-error+) > (apply custom-error-page args)) > (call-next-method)) > > Finally define custom-error-page: > > (defun custom-error-page (k1 error k2 backtrace) > (format nil > " > > >

whoops!

>

Error: ~a

> ~a > > " > error backtrace)) > > Don't forget to start your custom-acceptor like so: > > (tbnl:start (make-instance 'custom-acceptor ...)) > > Hope this helps. None of this code is tested by the way. > > Seb > -- > Emacs' AlsaPlayer - Music Without Jolts > Lightweight, full-featured and mindful of your idyllic happiness. > http://home.gna.org/eap > > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel From hans.huebner at gmail.com Tue Jul 24 18:42:53 2012 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Tue, 24 Jul 2012 20:42:53 +0200 Subject: [hunchentoot-devel] *show-lisp-errors-p* ignored? In-Reply-To: References: Message-ID: Andrei, I understand that your problem is solved now. Let me just point out that def-http-return-code is an internal macro that is not part of Hunchentoot's API and not mentioned in the documentation. I am not entirely opposed to making it part of the API if that'd be useful, and maybe you have a valid use case. Thus, if that would be easier than subclassing the acceptor class, maybe you can come up with a patch. -Hans On Tue, Jul 24, 2012 at 8:01 PM, Andrei Stebakov wrote: > Certainly, I was just wondering about the philosophy of the new error > handing mechanism. > I thought if it was based on custom http return codes defined by > def-http-return-code than the users would define their own using the > same mechanism. > > Thank you, > Andrei > > On Tue, Jul 24, 2012 at 11:41 AM, Hans H?bner wrote: >> Andrei, >> >> you are welcome to send patches if you feel that Hunchentoot lacks >> functionality that you need. Please use github pull requests. Do not forget >> to include documentation updates if you want to change the public API. >> >> Thanks, >> Hans >> >> Am 24.07.2012 16:32 schrieb "Andrei Stebakov" : >> >>> As I understand the whole acceptor-status-message has to be overloaded? >>> The user is discourage from defining their own (def-http-return-code >>> +some-user-code+ 777 "Some user message")? >>> >>> Andrei >>> >>> On Mon, Jul 23, 2012 at 4:19 PM, Hans H?bner >>> wrote: >>> > Andrei, >>> > >>> > you can implement a method for HUNCHENTOOT:ACCEPTOR-STATUS-MESSAGE >>> > (http://weitz.de/hunchentoot/#acceptor-status-message) specialized for >>> > your own acceptor class if the cooked message and the templating >>> > mechanism are insufficient for your needs. >>> > >>> > -Hans >>> > >>> > On Mon, Jul 23, 2012 at 10:08 PM, Andrei Stebakov >>> > wrote: >>> >> Thank you, Hans for the prompt response. >>> >> On the related subject, it used to be *http-error-handler* variable >>> >> that I set to a function where I handled all errors related to my own >>> >> run-time environment, (not hunchentoot related). >>> >> Basically before, I saved the error message in the hunchentoot >>> >> session-value and triggered (error ...) function. >>> >> My handler specified by *http-error-handler* would be called so I >>> >> generated an error page printing the saved message from the >>> >> session-value. >>> >> Now that the *http-error-handler* variable has been deprecated, what >>> >> is the best place I could put my own error page generation code? >>> >> >>> >> Thank you, >>> >> Andrei >>> >> >>> >> On Sat, Jul 14, 2012 at 2:20 AM, Hans H?bner >>> >> wrote: >>> >>> Andrei, >>> >>> >>> >>> the *show-lisp-errors-p* and *show-lisp-backtraces-p* are ignored if >>> >>> the acceptor has been instantiated with an error template directory, >>> >>> which is the default. You need to use :error-template-directory nil >>> >>> when instantiating the acceptor to use the cooked messaging feature, >>> >>> which looks at these variable settings. >>> >>> >>> >>> http://weitz.de/hunchentoot/#*show-lisp-errors-p* >>> >>> >>> >>> -Hans >>> >>> >>> >>> On Sat, Jul 14, 2012 at 6:24 AM, Andrei Stebakov >>> >>> wrote: >>> >>>> Hi >>> >>>> >>> >>>> I got following variables set before running Hunchentoot >>> >>>> >>> >>>> (setf hunchentoot:*catch-errors-p* t) >>> >>>> (setf hunchentoot:*show-lisp-errors-p* nil) >>> >>>> (setf hunchentoot:*log-lisp-errors-p* t) >>> >>>> (setf hunchentoot:*show-lisp-backtraces-p* nil) >>> >>>> >>> >>>> For some reason, when an error happens (or when I explicitly call >>> >>>> (error "test")), I still see the whole lisp backtrace printed in the >>> >>>> browser. >>> >>>> How do I fix this? It looks like make-cooked-message isn't called for >>> >>>> every request as well. >>> >>>> >>> >>>> Thank you, >>> >>>> Andrei >>> >>>> >>> >>>> _______________________________________________ >>> >>>> tbnl-devel site list >>> >>>> tbnl-devel at common-lisp.net >>> >>>> http://common-lisp.net/mailman/listinfo/tbnl-devel >>> >>> >>> >>> _______________________________________________ >>> >>> tbnl-devel site list >>> >>> tbnl-devel at common-lisp.net >>> >>> http://common-lisp.net/mailman/listinfo/tbnl-devel >>> >> >>> >> _______________________________________________ >>> >> tbnl-devel site list >>> >> tbnl-devel at common-lisp.net >>> >> http://common-lisp.net/mailman/listinfo/tbnl-devel >>> > >>> > _______________________________________________ >>> > tbnl-devel site list >>> > tbnl-devel at common-lisp.net >>> > http://common-lisp.net/mailman/listinfo/tbnl-devel >>> >>> _______________________________________________ >>> tbnl-devel site list >>> tbnl-devel at common-lisp.net >>> http://common-lisp.net/mailman/listinfo/tbnl-devel >> >> >> _______________________________________________ >> tbnl-devel site list >> tbnl-devel at common-lisp.net >> http://common-lisp.net/mailman/listinfo/tbnl-devel > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel From lispercat at gmail.com Tue Jul 24 22:46:41 2012 From: lispercat at gmail.com (Andrei Stebakov) Date: Tue, 24 Jul 2012 18:46:41 -0400 Subject: [hunchentoot-devel] *show-lisp-errors-p* ignored? In-Reply-To: References: Message-ID: Maybe I am doing something wrong, but I subclassed acceptor-status-message and it's called and the custom-error-page is called, but in the final page I still see output like: Internal Server Error The server encountered an internal error or misconfiguration and was unable to complete your request. Please contact the server administrator, info at domain.com and inform them of the time the error occurred, and anything you might have done that may have caused the error. More information about this error may be available in the server error log. Apache/2.2.8 (Ubuntu) PHP/5.2.4-2ubuntu5.19 with Suhosin-Patch mod_ssl/2.2.8 OpenSSL/0.9.8g Server at www.yourspecialtee.com Port 80 I wonder what's missing? On Tue, Jul 24, 2012 at 2:42 PM, Hans H?bner wrote: > Andrei, > > I understand that your problem is solved now. Let me just point out > that def-http-return-code is an internal macro that is not part of > Hunchentoot's API and not mentioned in the documentation. I am not > entirely opposed to making it part of the API if that'd be useful, and > maybe you have a valid use case. Thus, if that would be easier than > subclassing the acceptor class, maybe you can come up with a patch. > > -Hans > > On Tue, Jul 24, 2012 at 8:01 PM, Andrei Stebakov wrote: >> Certainly, I was just wondering about the philosophy of the new error >> handing mechanism. >> I thought if it was based on custom http return codes defined by >> def-http-return-code than the users would define their own using the >> same mechanism. >> >> Thank you, >> Andrei >> >> On Tue, Jul 24, 2012 at 11:41 AM, Hans H?bner wrote: >>> Andrei, >>> >>> you are welcome to send patches if you feel that Hunchentoot lacks >>> functionality that you need. Please use github pull requests. Do not forget >>> to include documentation updates if you want to change the public API. >>> >>> Thanks, >>> Hans >>> >>> Am 24.07.2012 16:32 schrieb "Andrei Stebakov" : >>> >>>> As I understand the whole acceptor-status-message has to be overloaded? >>>> The user is discourage from defining their own (def-http-return-code >>>> +some-user-code+ 777 "Some user message")? >>>> >>>> Andrei >>>> >>>> On Mon, Jul 23, 2012 at 4:19 PM, Hans H?bner >>>> wrote: >>>> > Andrei, >>>> > >>>> > you can implement a method for HUNCHENTOOT:ACCEPTOR-STATUS-MESSAGE >>>> > (http://weitz.de/hunchentoot/#acceptor-status-message) specialized for >>>> > your own acceptor class if the cooked message and the templating >>>> > mechanism are insufficient for your needs. >>>> > >>>> > -Hans >>>> > >>>> > On Mon, Jul 23, 2012 at 10:08 PM, Andrei Stebakov >>>> > wrote: >>>> >> Thank you, Hans for the prompt response. >>>> >> On the related subject, it used to be *http-error-handler* variable >>>> >> that I set to a function where I handled all errors related to my own >>>> >> run-time environment, (not hunchentoot related). >>>> >> Basically before, I saved the error message in the hunchentoot >>>> >> session-value and triggered (error ...) function. >>>> >> My handler specified by *http-error-handler* would be called so I >>>> >> generated an error page printing the saved message from the >>>> >> session-value. >>>> >> Now that the *http-error-handler* variable has been deprecated, what >>>> >> is the best place I could put my own error page generation code? >>>> >> >>>> >> Thank you, >>>> >> Andrei >>>> >> >>>> >> On Sat, Jul 14, 2012 at 2:20 AM, Hans H?bner >>>> >> wrote: >>>> >>> Andrei, >>>> >>> >>>> >>> the *show-lisp-errors-p* and *show-lisp-backtraces-p* are ignored if >>>> >>> the acceptor has been instantiated with an error template directory, >>>> >>> which is the default. You need to use :error-template-directory nil >>>> >>> when instantiating the acceptor to use the cooked messaging feature, >>>> >>> which looks at these variable settings. >>>> >>> >>>> >>> http://weitz.de/hunchentoot/#*show-lisp-errors-p* >>>> >>> >>>> >>> -Hans >>>> >>> >>>> >>> On Sat, Jul 14, 2012 at 6:24 AM, Andrei Stebakov >>>> >>> wrote: >>>> >>>> Hi >>>> >>>> >>>> >>>> I got following variables set before running Hunchentoot >>>> >>>> >>>> >>>> (setf hunchentoot:*catch-errors-p* t) >>>> >>>> (setf hunchentoot:*show-lisp-errors-p* nil) >>>> >>>> (setf hunchentoot:*log-lisp-errors-p* t) >>>> >>>> (setf hunchentoot:*show-lisp-backtraces-p* nil) >>>> >>>> >>>> >>>> For some reason, when an error happens (or when I explicitly call >>>> >>>> (error "test")), I still see the whole lisp backtrace printed in the >>>> >>>> browser. >>>> >>>> How do I fix this? It looks like make-cooked-message isn't called for >>>> >>>> every request as well. >>>> >>>> >>>> >>>> Thank you, >>>> >>>> Andrei >>>> >>>> >>>> >>>> _______________________________________________ >>>> >>>> tbnl-devel site list >>>> >>>> tbnl-devel at common-lisp.net >>>> >>>> http://common-lisp.net/mailman/listinfo/tbnl-devel >>>> >>> >>>> >>> _______________________________________________ >>>> >>> tbnl-devel site list >>>> >>> tbnl-devel at common-lisp.net >>>> >>> http://common-lisp.net/mailman/listinfo/tbnl-devel >>>> >> >>>> >> _______________________________________________ >>>> >> tbnl-devel site list >>>> >> tbnl-devel at common-lisp.net >>>> >> http://common-lisp.net/mailman/listinfo/tbnl-devel >>>> > >>>> > _______________________________________________ >>>> > tbnl-devel site list >>>> > tbnl-devel at common-lisp.net >>>> > http://common-lisp.net/mailman/listinfo/tbnl-devel >>>> >>>> _______________________________________________ >>>> tbnl-devel site list >>>> tbnl-devel at common-lisp.net >>>> http://common-lisp.net/mailman/listinfo/tbnl-devel >>> >>> >>> _______________________________________________ >>> tbnl-devel site list >>> tbnl-devel at common-lisp.net >>> http://common-lisp.net/mailman/listinfo/tbnl-devel >> >> _______________________________________________ >> tbnl-devel site list >> tbnl-devel at common-lisp.net >> http://common-lisp.net/mailman/listinfo/tbnl-devel > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel From hans.huebner at gmail.com Wed Jul 25 05:43:48 2012 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Wed, 25 Jul 2012 07:43:48 +0200 Subject: [hunchentoot-devel] *show-lisp-errors-p* ignored? In-Reply-To: References: Message-ID: Andrei, the error page that you have sent was generated by Apache, not Hunchentoot. -Hans On Wed, Jul 25, 2012 at 12:46 AM, Andrei Stebakov wrote: > Maybe I am doing something wrong, but I subclassed > acceptor-status-message and it's called and the custom-error-page is > called, but in the final page I still see output like: > > Internal Server Error > The server encountered an internal error or misconfiguration and was > unable to complete your request. > Please contact the server administrator, info at domain.com and inform > them of the time the error occurred, and anything you might have done > that may have caused the error. > More information about this error may be available in the server error log. > Apache/2.2.8 (Ubuntu) PHP/5.2.4-2ubuntu5.19 with Suhosin-Patch > mod_ssl/2.2.8 OpenSSL/0.9.8g Server at www.yourspecialtee.com Port 80 > > I wonder what's missing? > > On Tue, Jul 24, 2012 at 2:42 PM, Hans H?bner wrote: >> Andrei, >> >> I understand that your problem is solved now. Let me just point out >> that def-http-return-code is an internal macro that is not part of >> Hunchentoot's API and not mentioned in the documentation. I am not >> entirely opposed to making it part of the API if that'd be useful, and >> maybe you have a valid use case. Thus, if that would be easier than >> subclassing the acceptor class, maybe you can come up with a patch. >> >> -Hans >> >> On Tue, Jul 24, 2012 at 8:01 PM, Andrei Stebakov wrote: >>> Certainly, I was just wondering about the philosophy of the new error >>> handing mechanism. >>> I thought if it was based on custom http return codes defined by >>> def-http-return-code than the users would define their own using the >>> same mechanism. >>> >>> Thank you, >>> Andrei >>> >>> On Tue, Jul 24, 2012 at 11:41 AM, Hans H?bner wrote: >>>> Andrei, >>>> >>>> you are welcome to send patches if you feel that Hunchentoot lacks >>>> functionality that you need. Please use github pull requests. Do not forget >>>> to include documentation updates if you want to change the public API. >>>> >>>> Thanks, >>>> Hans >>>> >>>> Am 24.07.2012 16:32 schrieb "Andrei Stebakov" : >>>> >>>>> As I understand the whole acceptor-status-message has to be overloaded? >>>>> The user is discourage from defining their own (def-http-return-code >>>>> +some-user-code+ 777 "Some user message")? >>>>> >>>>> Andrei >>>>> >>>>> On Mon, Jul 23, 2012 at 4:19 PM, Hans H?bner >>>>> wrote: >>>>> > Andrei, >>>>> > >>>>> > you can implement a method for HUNCHENTOOT:ACCEPTOR-STATUS-MESSAGE >>>>> > (http://weitz.de/hunchentoot/#acceptor-status-message) specialized for >>>>> > your own acceptor class if the cooked message and the templating >>>>> > mechanism are insufficient for your needs. >>>>> > >>>>> > -Hans >>>>> > >>>>> > On Mon, Jul 23, 2012 at 10:08 PM, Andrei Stebakov >>>>> > wrote: >>>>> >> Thank you, Hans for the prompt response. >>>>> >> On the related subject, it used to be *http-error-handler* variable >>>>> >> that I set to a function where I handled all errors related to my own >>>>> >> run-time environment, (not hunchentoot related). >>>>> >> Basically before, I saved the error message in the hunchentoot >>>>> >> session-value and triggered (error ...) function. >>>>> >> My handler specified by *http-error-handler* would be called so I >>>>> >> generated an error page printing the saved message from the >>>>> >> session-value. >>>>> >> Now that the *http-error-handler* variable has been deprecated, what >>>>> >> is the best place I could put my own error page generation code? >>>>> >> >>>>> >> Thank you, >>>>> >> Andrei >>>>> >> >>>>> >> On Sat, Jul 14, 2012 at 2:20 AM, Hans H?bner >>>>> >> wrote: >>>>> >>> Andrei, >>>>> >>> >>>>> >>> the *show-lisp-errors-p* and *show-lisp-backtraces-p* are ignored if >>>>> >>> the acceptor has been instantiated with an error template directory, >>>>> >>> which is the default. You need to use :error-template-directory nil >>>>> >>> when instantiating the acceptor to use the cooked messaging feature, >>>>> >>> which looks at these variable settings. >>>>> >>> >>>>> >>> http://weitz.de/hunchentoot/#*show-lisp-errors-p* >>>>> >>> >>>>> >>> -Hans >>>>> >>> >>>>> >>> On Sat, Jul 14, 2012 at 6:24 AM, Andrei Stebakov >>>>> >>> wrote: >>>>> >>>> Hi >>>>> >>>> >>>>> >>>> I got following variables set before running Hunchentoot >>>>> >>>> >>>>> >>>> (setf hunchentoot:*catch-errors-p* t) >>>>> >>>> (setf hunchentoot:*show-lisp-errors-p* nil) >>>>> >>>> (setf hunchentoot:*log-lisp-errors-p* t) >>>>> >>>> (setf hunchentoot:*show-lisp-backtraces-p* nil) >>>>> >>>> >>>>> >>>> For some reason, when an error happens (or when I explicitly call >>>>> >>>> (error "test")), I still see the whole lisp backtrace printed in the >>>>> >>>> browser. >>>>> >>>> How do I fix this? It looks like make-cooked-message isn't called for >>>>> >>>> every request as well. >>>>> >>>> >>>>> >>>> Thank you, >>>>> >>>> Andrei >>>>> >>>> >>>>> >>>> _______________________________________________ >>>>> >>>> tbnl-devel site list >>>>> >>>> tbnl-devel at common-lisp.net >>>>> >>>> http://common-lisp.net/mailman/listinfo/tbnl-devel >>>>> >>> >>>>> >>> _______________________________________________ >>>>> >>> tbnl-devel site list >>>>> >>> tbnl-devel at common-lisp.net >>>>> >>> http://common-lisp.net/mailman/listinfo/tbnl-devel >>>>> >> >>>>> >> _______________________________________________ >>>>> >> tbnl-devel site list >>>>> >> tbnl-devel at common-lisp.net >>>>> >> http://common-lisp.net/mailman/listinfo/tbnl-devel >>>>> > >>>>> > _______________________________________________ >>>>> > tbnl-devel site list >>>>> > tbnl-devel at common-lisp.net >>>>> > http://common-lisp.net/mailman/listinfo/tbnl-devel >>>>> >>>>> _______________________________________________ >>>>> tbnl-devel site list >>>>> tbnl-devel at common-lisp.net >>>>> http://common-lisp.net/mailman/listinfo/tbnl-devel >>>> >>>> >>>> _______________________________________________ >>>> tbnl-devel site list >>>> tbnl-devel at common-lisp.net >>>> http://common-lisp.net/mailman/listinfo/tbnl-devel >>> >>> _______________________________________________ >>> tbnl-devel site list >>> tbnl-devel at common-lisp.net >>> http://common-lisp.net/mailman/listinfo/tbnl-devel >> >> _______________________________________________ >> tbnl-devel site list >> tbnl-devel at common-lisp.net >> http://common-lisp.net/mailman/listinfo/tbnl-devel > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel