Revision: 4511
Author: hans
URL: http://bknr.net/trac/changeset/4511
Replace some uses of HANDLER-CASE* with HANDLER-CASE. These are catching
specific error conditions which are internal to Hunchentoot and not relevant
to a user who is debugging his own handlers. Reported by Allan Dee.
U trunk/thirdparty/hunchentoot/acceptor.lisp
U trunk/thirdparty/hunchentoot/headers.lisp
U trunk/thirdparty/hunchentoot/request.lisp
Modified: trunk/thirdparty/hunchentoot/acceptor.lisp
===================================================================
--- trunk/thirdparty/hunchentoot/acceptor.lisp 2010-02-16 21:14:38 UTC (rev 4510)
+++ trunk/thirdparty/hunchentoot/acceptor.lisp 2010-02-17 06:12:43 UTC (rev 4511)
@@ -375,7 +375,7 @@
(return))
(when (usocket:wait-for-input listener :ready-only t :timeout +new-connection-wait-time+)
(when-let (client-connection
- (handler-case* (usocket:socket-accept listener)
+ (handler-case (usocket:socket-accept listener)
;; ignore condition
(usocket:connection-aborted-error ())))
(set-timeouts client-connection
Modified: trunk/thirdparty/hunchentoot/headers.lisp
===================================================================
--- trunk/thirdparty/hunchentoot/headers.lisp 2010-02-16 21:14:38 UTC (rev 4510)
+++ trunk/thirdparty/hunchentoot/headers.lisp 2010-02-17 06:12:43 UTC (rev 4511)
@@ -238,7 +238,7 @@
to close the connection instead, a timeout indicates that the
connection timeout established by Hunchentoot has expired and we do
not want to wait for another request any longer."
- (handler-case*
+ (handler-case
(let ((*current-error-message* "While reading initial request line:"))
(with-mapped-conditions ()
(read-line* stream)))
Modified: trunk/thirdparty/hunchentoot/request.lisp
===================================================================
--- trunk/thirdparty/hunchentoot/request.lisp 2010-02-16 21:14:38 UTC (rev 4510)
+++ trunk/thirdparty/hunchentoot/request.lisp 2010-02-17 06:12:43 UTC (rev 4511)
@@ -283,7 +283,7 @@
(parse-content-type (header-in :content-type request))
(let ((external-format (or external-format
(when charset
- (handler-case*
+ (handler-case
(make-external-format charset :eol-style :lf)
(error ()
(hunchentoot-warn "Ignoring ~
@@ -467,7 +467,7 @@
returned."
(when content-type
(when-let (charset (nth-value 2 (parse-content-type content-type)))
- (handler-case*
+ (handler-case
(make-external-format (as-keyword charset) :eol-style :lf)
(error ()
(hunchentoot-warn "Invalid character set ~S in request has been ignored."
Revision: 4495
Author: edi
URL: http://bknr.net/trac/changeset/4495
changelog
U trunk/thirdparty/hunchentoot/CHANGELOG
Modified: trunk/thirdparty/hunchentoot/CHANGELOG
===================================================================
--- trunk/thirdparty/hunchentoot/CHANGELOG 2009-12-28 16:40:26 UTC (rev 4494)
+++ trunk/thirdparty/hunchentoot/CHANGELOG 2009-12-28 16:41:17 UTC (rev 4495)
@@ -2,10 +2,11 @@
Re-introduced *CATCH-ERRORS-P* and MAYBE-INVOKE-DEBUGGER
Integration with trivial-backtrace (see *LOG-LISP-BACKTRACES-P*)
Treat :UNSPECIFIC like NIL in pathname components (reported by Frode Fjeld)
-Prepare for LispWorks 6 (Nico de Jager)
-Fix reading of post parameters (Peter Seibel and Stephen P. Compall)
-Fix STOP by supplying the :READY-ONLY keyword to USOCKET:WAIT-FOR-INPUT
-Enable SSL key passwords for Lisps other than LW (Vsevolod)
+Fixed RESET-SESSIONS
+Prepared for LispWorks 6 (Nico de Jager)
+Fixed reading of post parameters (Peter Seibel and Stephen P. Compall)
+Fixed STOP by supplying the :READY-ONLY keyword to USOCKET:WAIT-FOR-INPUT
+Enabled SSL key passwords for Lisps other than LW (Vsevolod)
Version 1.0.0
2009-02-19
Revision: 4493
Author: edi
URL: http://bknr.net/trac/changeset/4493
Missing changelog entry
U trunk/thirdparty/hunchentoot/CHANGELOG
Modified: trunk/thirdparty/hunchentoot/CHANGELOG
===================================================================
--- trunk/thirdparty/hunchentoot/CHANGELOG 2009-12-27 23:12:39 UTC (rev 4492)
+++ trunk/thirdparty/hunchentoot/CHANGELOG 2009-12-27 23:14:59 UTC (rev 4493)
@@ -3,7 +3,7 @@
Integration with trivial-backtrace (see *LOG-LISP-BACKTRACES-P*)
Treat :UNSPECIFIC like NIL in pathname components (reported by Frode Fjeld)
Prepare for LispWorks 6 (Nico de Jager)
-Fix reading of post parameters (Peter Seibel)
+Fix reading of post parameters (Peter Seibel and Stephen P. Compall)
Fix STOP by supplying the :READY-ONLY keyword to USOCKET:WAIT-FOR-INPUT
Enable SSL key passwords for Lisps other than LW (Vsevolod)
Revision: 4491
Author: edi
URL: http://bknr.net/trac/changeset/4491
Documentation
U trunk/thirdparty/hunchentoot/doc/index.xml
U trunk/thirdparty/hunchentoot/request.lisp
Modified: trunk/thirdparty/hunchentoot/doc/index.xml
===================================================================
--- trunk/thirdparty/hunchentoot/doc/index.xml 2009-12-27 21:10:34 UTC (rev 4490)
+++ trunk/thirdparty/hunchentoot/doc/index.xml 2009-12-27 21:53:14 UTC (rev 4491)
@@ -613,18 +613,11 @@
stream object in <clix:arg>socket</clix:arg>. It reads the request headers, sets up the
<a href="#requests">request</a> and <a href="#replies">reply</a>
objects, and hands over to <clix:ref>PROCESS-REQUEST</clix:ref> which
-selects and calls a handler for the request and sends its reply to the
-client. This is done in a loop until the stream has to be closed or
-until a connection timeout occurs.
-
-<p>
-It is probably not a good idea to re-implement this method until you
-really, really know what you're doing, but you can for example write
-an around method specialized for your subclass
-of <clix:ref>ACCEPTOR</clix:ref> which binds or rebinds special
-variables which can then be accessed by
-your <a href="#handlers">handlers</a>.
-</p>
+calls <clix:ref>HANDLE-REQUEST</clix:ref> to select and call a handler
+for the request and sends its reply to the client. This is done in a
+loop until the stream has to be closed or until a connection timeout
+occurs. It is probably not a good idea to re-implement this method
+until you really, really know what you're doing.
</clix:description>
</clix:function>
@@ -766,35 +759,41 @@
<clix:subchapter name="request-dispatch" title="Request dispatch and handling">
-The main job of <clix:ref>PROCESS-REQUEST</clix:ref> is to select and
+The main job of <clix:ref>HANDLE-REQUEST</clix:ref> is to select and
call a function which handles the request, i.e. which looks at the
data the client has sent and prepares an appropriate reply to send
-back. This is implemented as follows:
+back. This is by default implemented as follows:
<p>
Each acceptor has a <a href="#acceptor-request-dispatcher"><em>request
dispatcher</em></a> which is a unary function that accepts
-a <clix:ref>REQUEST</clix:ref> object. This function is called by
-<clix:ref>PROCESS-REQUEST</clix:ref>. The idea is that this function
-looks at the request object and depending on its contents decides to
-call another function which "does the work". This "other" function is
-by convention called a <a class="none" name="handlers"><em>request
-handler</em></a>. (Obviously, this is really only a convention as
-process-request doesn't "know" what the request dispatcher does. You
-could as well say that the request dispatcher and the request handler
-have the same job.)
+a <clix:ref>REQUEST</clix:ref> object. This function is called by the
+default method of <clix:ref>HANDLE-REQUEST</clix:ref>. The idea is
+that this function looks at the request object and depending on its
+contents decides to call another function which "does the work". This
+"other" function is by convention called a <a class="none"
+name="handlers"><em>request handler</em></a>. (Obviously, this is
+really only a convention as <clix:ref>HANDLE-REQUEST</clix:ref>
+doesn't "know" what the request dispatcher does. You could as well
+say that the request dispatcher and the request handler have the same
+job.)
</p>
<p>
-The default behaviour, unless you implement your own request
+The default behaviour, unless your acceptor has its own request
dispatcher, is that Hunchentoot walks through the list
-*dispatch-table* which consists of <em>dispatch functions</em>. Each
-of these functions accepts the request object as its only argument and
-either returns a request handler to handle the request
-or <code>NIL</code> which means that the next dispatcher in the list
-will be tried. If all dispatch functions return <code>NIL</code>, the
-return code
+<clix:ref>*DISPATCH-TABLE*</clix:ref> which consists of <em>dispatch
+functions</em>. Each of these functions accepts the request object as
+its only argument and either returns a request handler to handle the
+request or <code>NIL</code> which means that the next dispatcher in
+the list will be tried. If all dispatch functions
+return <code>NIL</code>, the return code
<clix:ref>+HTTP-NOT-FOUND+</clix:ref> will be sent to the client.
</p>
<p>
+The default method of <clix:ref>HANDLE-REQUEST</clix:ref> also sets up
+<a href="#logging">standard error handling</a> before it calls the acceptor's request
+dispatcher.
+</p>
+<p>
All functions and variables in this section are related to the
standard request dispatch mechanism described above and are
meaningless if you're using your own request dispatcher.
@@ -1570,24 +1569,48 @@
</clix:returns>
<clix:description>
This function is called by <clix:ref>PROCESS-CONNECTION</clix:ref>
-after the incoming headers have been read. It selects and calls a
-<a href="#handlers">handler</a> and sends the output of this handler
-to the client. It also sets up simple error handling for the request
-handler. Note that <clix:ref>PROCESS-CONNECTION</clix:ref> is called
-once per connection and loops in case of a persistent connection
-while <clix:ref>PROCESS-REQUEST</clix:ref> is called anew for each
-request.
+after the incoming headers have been read. It
+calls <clix:ref>HANDLE-REQUEST</clix:ref> (and is more or less just a
+thin wrapper around it) to select and call a
+<a href="#handlers">handler</a> and send the output of this handler to
+the client. Note that <clix:ref>PROCESS-CONNECTION</clix:ref> is
+called once per connection and loops in case of a persistent
+connection while <clix:ref>PROCESS-REQUEST</clix:ref> is called anew
+for each request.
<p>
-Like <clix:ref>PROCESS-CONNECTION</clix:ref>, this might be a good
-place to introduce around methods which bind special variables or do
-other interesting things.
+The return value of this function is ignored.
</p>
<p>
-The return value of this function is ignored.
+Like <clix:ref>PROCESS-CONNECTION</clix:ref>, this is another function
+the behaviour of which you should only modify if you really, really
+know what you're doing.
</p>
</clix:description>
</clix:function>
+ <clix:function generic='true' name='handle-request'>
+ <clix:lambda-list>acceptor request
+ </clix:lambda-list>
+ <clix:returns>content
+ </clix:returns>
+ <clix:description>
+This function is called by <clix:ref>PROCESS-REQUEST</clix:ref> once
+the request has been read and a <clix:ref>REQUEST</clix:ref> object
+has been created. Its job is to actually handle the request, i.e. to
+return something to the client.
+<p>
+The default method calls the
+acceptor's <a href="#request-dispatch">request dispatcher</a>, but you
+can of course implement a different behaviour. The default method
+also sets up <a href="#logging">standard error handling</a> for
+the <a href="#handlers">handler</a>.
+</p>
+<p>
+Might be a good place to bind or rebind special variables which can
+then be accessed by your <a href="#handlers">handlers</a>.
+</p>
+ </clix:description>
+ </clix:function>
<clix:readers generic='true'>
Modified: trunk/thirdparty/hunchentoot/request.lisp
===================================================================
--- trunk/thirdparty/hunchentoot/request.lisp 2009-12-27 21:10:34 UTC (rev 4490)
+++ trunk/thirdparty/hunchentoot/request.lisp 2009-12-27 21:53:14 UTC (rev 4491)
@@ -97,16 +97,14 @@
(defgeneric process-request (request)
(:documentation "This function is called by PROCESS-CONNECTION after
-the incoming headers have been read. It selects and calls a handler
-and sends the output of this handler to the client using START-OUTPUT.
-It also sets up simple error handling for the request handler. Note
-that PROCESS-CONNECTION is called once per connection and loops in
-case of a persistent connection while PROCESS-REQUEST is called anew
-for each request.
+the incoming headers have been read. It calls HANDLE-REQUEST to
+select and call a handler and sends the output of this handler to the
+client using START-OUTPUT. Note that PROCESS-CONNECTION is called
+once per connection and loops in case of a persistent connection while
+PROCESS-REQUEST is called anew for each request.
-Like PROCESS-CONNECTION, this might be a good place to introduce
-around methods which bind special variables or do other interesting
-things.
+Essentially, you can view process-request as a thin wrapper around
+HANDLE-REQUEST.
The return value of this function is ignored."))
Revision: 4490
Author: edi
URL: http://bknr.net/trac/changeset/4490
Resurrect *catch-errors-p* and more
Some documentation still has to be updated
U trunk/thirdparty/hunchentoot/CHANGELOG
U trunk/thirdparty/hunchentoot/acceptor.lisp
U trunk/thirdparty/hunchentoot/conditions.lisp
U trunk/thirdparty/hunchentoot/doc/index.xml
U trunk/thirdparty/hunchentoot/easy-handlers.lisp
U trunk/thirdparty/hunchentoot/headers.lisp
D trunk/thirdparty/hunchentoot/hunchentoot-test.asd
U trunk/thirdparty/hunchentoot/hunchentoot.asd
U trunk/thirdparty/hunchentoot/lispworks.lisp
U trunk/thirdparty/hunchentoot/packages.lisp
U trunk/thirdparty/hunchentoot/request.lisp
U trunk/thirdparty/hunchentoot/specials.lisp
U trunk/thirdparty/hunchentoot/taskmaster.lisp
U trunk/thirdparty/hunchentoot/url-rewrite/primitives.lisp
Change set too large, please see URL above
Revision: 4489
Author: edi
URL: http://bknr.net/trac/changeset/4489
Revoke commit 4477
U trunk/thirdparty/hunchentoot/doc/index.xml
U trunk/thirdparty/hunchentoot/packages.lisp
U trunk/thirdparty/hunchentoot/request.lisp
Modified: trunk/thirdparty/hunchentoot/doc/index.xml
===================================================================
--- trunk/thirdparty/hunchentoot/doc/index.xml 2009-12-22 22:14:35 UTC (rev 4488)
+++ trunk/thirdparty/hunchentoot/doc/index.xml 2009-12-22 22:28:12 UTC (rev 4489)
@@ -1594,33 +1594,17 @@
</clix:returns>
<clix:description>
This function is called by <clix:ref>PROCESS-CONNECTION</clix:ref>
-after the incoming headers have been read. It
-calls <clix:ref>DISPATCH-REQUEST</clix:ref> and sends its output to
-the client. It also sets up simple error handling for the request
-handler.
-<p>
-The return value of this function is ignored.
-</p>
- </clix:description>
- </clix:function>
-
- <clix:function generic='true' name='dispatch-request'>
- <clix:lambda-list>request
- </clix:lambda-list>
- <clix:returns>nil
- </clix:returns>
- <clix:description>
-This function is called by <clix:ref>PROCESS-REQUEST</clix:ref>. It
-selects and calls a
-<a href="#handlers">handler</a> to process the request.
-<p>
-This might be a good place to introduce around methods which bind
-special variables or do other interesting things that are relevant to
-the particular request. Note
-that <clix:ref>DISPATCH-REQUEST</clix:ref> is called once per
-connection and loops in case of a persistent connection,
+after the incoming headers have been read. It selects and calls a
+<a href="#handlers">handler</a> and sends the output of this handler
+to the client. It also sets up simple error handling for the request
+handler. Note that <clix:ref>PROCESS-CONNECTION</clix:ref> is called
+once per connection and loops in case of a persistent connection
while <clix:ref>PROCESS-REQUEST</clix:ref> is called anew for each
request.
+<p>
+Like <clix:ref>PROCESS-CONNECTION</clix:ref>, this might be a good
+place to introduce around methods which bind special variables or do
+other interesting things.
</p>
<p>
The return value of this function is ignored.
Modified: trunk/thirdparty/hunchentoot/packages.lisp
===================================================================
--- trunk/thirdparty/hunchentoot/packages.lisp 2009-12-22 22:14:35 UTC (rev 4488)
+++ trunk/thirdparty/hunchentoot/packages.lisp 2009-12-22 22:28:12 UTC (rev 4489)
@@ -167,7 +167,6 @@
"DELETE-AUX-REQUEST-VALUE"
"DELETE-SESSION-VALUE"
"DISPATCH-EASY-HANDLERS"
- "DISPATCH-REQUEST"
"ESCAPE-FOR-HTML"
"EXECUTE-ACCEPTOR"
"GET-PARAMETER"
Modified: trunk/thirdparty/hunchentoot/request.lisp
===================================================================
--- trunk/thirdparty/hunchentoot/request.lisp 2009-12-22 22:14:35 UTC (rev 4488)
+++ trunk/thirdparty/hunchentoot/request.lisp 2009-12-22 22:28:12 UTC (rev 4489)
@@ -95,22 +95,21 @@
can subclass REQUEST in order to implement your own behaviour. See
the REQUEST-CLASS slot of the ACCEPTOR class."))
-(defgeneric dispatch-request (request)
- (:documentation "This function is called by PROCESS-REQUEST. It
-selects and calls a handler to process the request.
-
-This might be a good place to introduce around methods which bind
-special variables or do other interesting things that are relevant to
-the particular request. Note that DISPATCH-REQUEST is called once per
-connection and loops in case of a persistent connection, while
-PROCESS-REQUEST is called anew for each request."))
-
(defgeneric process-request (request)
(:documentation "This function is called by PROCESS-CONNECTION after
-the incoming headers have been read. It calls DISPATCH-REQUEST and
-sends its output to the client. It also sets up simple error handling
-for the request handler."))
+the incoming headers have been read. It selects and calls a handler
+and sends the output of this handler to the client using START-OUTPUT.
+It also sets up simple error handling for the request handler. Note
+that PROCESS-CONNECTION is called once per connection and loops in
+case of a persistent connection while PROCESS-REQUEST is called anew
+for each request.
+Like PROCESS-CONNECTION, this might be a good place to introduce
+around methods which bind special variables or do other interesting
+things.
+
+The return value of this function is ignored."))
+
(defun convert-hack (string external-format)
"The rfc2388 package is buggy in that it operates on a character
stream and thus only accepts encodings which are 8 bit transparent.
@@ -211,12 +210,6 @@
;; we assume it's not our fault...
(setf (return-code*) +http-bad-request+)))))
-(defmethod dispatch-request (request)
- "Standard implementation of dispatching a request to the appropriate
-handler."
- (funcall (acceptor-request-dispatcher *acceptor*)
- request))
-
(defmethod process-request (request)
"Standard implementation for processing a request. You should not
change or replace this functionality unless you know what you're
@@ -233,7 +226,7 @@
;; skip dispatch if bad request
(when (eql (return-code *reply*) +http-ok+)
;; now do the work
- (dispatch-request request)))))
+ (funcall (acceptor-request-dispatcher *acceptor*) *request*)))))
(when error
(setf (return-code *reply*)
+http-internal-server-error+))