Hi,
sorry about that first email -- I am still learning gmail and hadn't realised I was rudely sending HTML. Trying again in plain text:
We have a web server giving Json responses. For proper failures it returns a non-200 status code and a failure description in the status message (e.g. the status line reads "HTTP/1.0 400 Empty method name". AFAICS this status message is not passed through by Drakma's http-request.
I locally made the attached changes (doing so, I found that read-status-line added the leading separating whitespace to its third value; I fixed that as well). Any chance of having this or some other means to get to the message in the official code?
Holger
diff -rN -u old-drakma/read.lisp new-drakma/read.lisp --- old-drakma/read.lisp 2007-06-27 12:23:17.000000000 +0100 +++ new-drakma/read.lisp 2007-06-27 12:23:17.000000000 +0100 @@ -55,7 +55,7 @@ :start (1+ first-space-pos) :end second-space-pos)) (error "Status code in ~S is not an integer." line)) - (and second-space-pos (subseq line second-space-pos))))) + (and second-space-pos (subseq line (1+ second-space-pos))))))
(defun get-content-type (headers) "Reads and parses a `Content-Type' header and returns it as @@ -124,4 +124,4 @@ (trim-whitespace (subseq string (1+ old-position) position))) while old-position when (plusp (length substring)) - collect substring)) \ No newline at end of file + collect substring)) diff -rN -u old-drakma/request.lisp new-drakma/request.lisp --- old-drakma/request.lisp 2007-06-27 12:23:17.000000000 +0100 +++ new-drakma/request.lisp 2007-06-27 12:23:17.000000000 +0100 @@ -172,15 +172,15 @@ URI is where the request is sent to, and it is either a string denoting a uniform resource identifier or a PURI:URI object. The scheme of URI must be `http' or `https'. The function returns -SIX values - the body of the reply (but see below), the status +SEVEN values - the body of the reply (but see below), the status code as an integer, an alist of the headers sent by the server where for each element the car (the name of the header) is a keyword and the cdr (the value of the header) is a string, the URI the reply comes from (which might be different from the URI the request was sent to in case of redirects), the stream the -reply was read from, and a generalized boolean which denotes +reply was read from, a generalized boolean which denotes whether the stream should be closed (and which you can usually -ignore). +ignore), and the message text from the response line.
PROTOCOL is the HTTP protocol which is going to be used in the request line, it must be one of the keywords :HTTP/1.0 or @@ -512,15 +512,15 @@ (setf (chunked-stream-output-chunking-p (flexi-stream-stream http-stream)) nil) (finish-output http-stream) - (multiple-value-bind (server-protocol status-code) + (multiple-value-bind (server-protocol status-code status-text) ;; loop until status is NOT 100 - (loop for (server-protocol status-code nil) + (loop for (server-protocol status-code status-text) = (read-status-line http-stream *header-stream*) when (= status-code 100) ;; ignore headers sent until non-100 status is seen do (read-http-headers http-stream *header-stream*) until (/= status-code 100) - finally (return (values server-protocol status-code))) + finally (return (values server-protocol status-code status-text))) (let ((headers (read-http-headers http-stream *header-stream*)) body external-format-body) (let ((connections (header-value :connection headers))) @@ -631,7 +631,8 @@ headers uri http-stream - must-close))))) + must-close + status-text))))) (when (eq content :continuation) (return-from http-request #'finish-request)) (finish-request content))))
On Wed, 27 Jun 2007 21:17:23 +0100, "H Duerer" h.duerer@gmail.com wrote:
sorry about that first email -- I am still learning gmail and hadn't realised I was rudely sending HTML.
The first email was multipart/alternative which is fine, at least for Gnus users like me. The problem with the second email was that Gmail inserted gratuitous line breaks which rendered the (inlined) diff unusable.
Anyway, thanks for the patch, it's in 0.9.0. The next time you send a patch, please make sure to update the HTML documentation as well.
Cheers, Edi.