This is exaclty what I need. The GET method works just fine, but I have trouble with the POST method uploading the files. Edi, here is a question (I am not sure if it's the right mailing list to ask it...) When I say (this is part of a function, so I use back-quote for parameters):
(drakma:http-request "/some/uri" :method :post :form-data t :parameters `(("Name1" . ,name1) ("Name2" . ,name2) ("File" . ,file-name))))
I got an "unknown error" from the remote host. Looks like there is problem with streaming file contents. I did a little of debugging printing the content of file buffer (in send-content function) looks like the file is being open and read, but something happens at the receiving end. I wonder how can I debug it more. When I do the same request from the FORM in Firefox everything works. What debuggind techniques I can try here? (Sorry I am still very new to Lisp)
Thank you, Andrew
"Andrei Stebakov" lispercat@gmail.com writes:
This is exaclty what I need. The GET method works just fine, but I have trouble with the POST method uploading the files.
I've never used POST with drakma. So I can only offer very general advice.
One way to debug the system is to test against your own server. You could, for example, use hunchentoot to easily create a test webserver. Once you have control of the server you can debug both sides of the problem.
Cheers, Chris Dean
On Mon, 12 Feb 2007 12:53:59 -0800, Chris Dean ctdean@sokitomi.com wrote:
One way to debug the system is to test against your own server. You could, for example, use hunchentoot to easily create a test webserver. Once you have control of the server you can debug both sides of the problem.
Of course, this won't help much if Hunchentoot and the /real/ server behave differently. (See my other email for an example - Hunchentoot knows how to handle chunked transfer encoding used by clients, Apache 1.x doesn't.)
Another way to debug Drakma it to use *HEADER-STREAM* to see at least the headers flying by.
http://weitz.de/drakma/#*header-stream*
Or use something like Ethereal (or whatever it is called nowadays).
The headers printed are following:
GET /authentication.getToken.cp?appKey=1234 HTTP/1.1 Host: domain.com User-Agent: Drakma/0.6.0 (CMU Common Lisp CVS release-19a 19a-release-20040728 + minimal debian patches; Linux; Linux version 2.2.20-idepci (herbert@gondolin) (gcc version 2.7.2.3) #1 Sat Apr 20 12:45:19 EST 2002; http://weitz.de/drakma/) Accept: */* Connection: close
HTTP/1.1 200 OK Cache-Control: private Content-Length: 74 Content-Type: text/xml Date: Wed, 14 Feb 2007 18:52:53 GMT Connection: close
POST /image.upload.cp HTTP/1.1 Host: domain.com User-Agent: Drakma/0.6.0 (CMU Common Lisp CVS release-19a 19a-release-20040728 + minimal debian patches; Linux; Linux version 2.2.20-idepci (herbert@gondolin) (gcc version 2.7.2.3) #1 Sat Apr 20 12:45:19 EST 2002; http://weitz.de/drakma/) Accept: */* Connection: close Content-Type: multipart/form-data; boundary=----------WueD0PVGvZzxvyK3835D6znnVITzpU5zaysqeYq41qhj1Nlv79 Content-Length: 521
HTTP/1.1 100 Continue
HTTP/1.1 200 OK Cache-Control: private Content-Length: 94 Content-Type: text/xml; charset=utf-8 Date: Wed, 14 Feb 2007 18:53:01 GMT Set-Cookie: Coyote-2-c0a8017a=c0a8073f:0;Max-Age=1800;Path=/ Connection: close
((:CACHE-CONTROL . "private") (:CONTENT-LENGTH . "94") (:CONTENT-TYPE . "text/xml; charset=utf-8") (:DATE . "Wed, 14 Feb 2007 18:53:01 GMT") (:SET-COOKIE . "Coyote-2-c0a8017a=c0a8073f:0;Max-Age=1800;Path=/") (:CONNECTION . "close"))
Maybe, as you mentioned, it's that the server I am trying to upload images to doesn't understand chunked stream?
Thank you, Andrew
On 2/12/07, Edi Weitz edi@agharta.de wrote:
On Mon, 12 Feb 2007 12:53:59 -0800, Chris Dean ctdean@sokitomi.com wrote:
One way to debug the system is to test against your own server. You could, for example, use hunchentoot to easily create a test webserver. Once you have control of the server you can debug both sides of the problem.
Of course, this won't help much if Hunchentoot and the /real/ server behave differently. (See my other email for an example - Hunchentoot knows how to handle chunked transfer encoding used by clients, Apache 1.x doesn't.)
Another way to debug Drakma it to use *HEADER-STREAM* to see at least the headers flying by.
http://weitz.de/drakma/#*header-stream*
Or use something like Ethereal (or whatever it is called nowadays). _______________________________________________ drakma-devel mailing list drakma-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/drakma-devel
Hi Edi,
First of all sorry for bringing it to the lisp NG. I didn't want to discuss it there, I just wanted to hear what libs are available. For some reason, my gmail client didn't show your messages so the last one was the one from Chris. Basically setting :CONTENT-LENGTH T and sending a pathname object instead of string solve the problem. Now I understand that with :CONTENT-LENGTH nil it was sending the chunked data. I still don't understand why when I send the request without :CONTENT-LENGTH T and giving a file name starting with p# the lisp process hangs (cmucl), maybe it's just the lisp implementation. Anyway, the problem solved, thank you Edi and Chris!
Andrew
On 2/12/07, Edi Weitz edi@agharta.de wrote:
On Mon, 12 Feb 2007 12:53:59 -0800, Chris Dean ctdean@sokitomi.com wrote:
One way to debug the system is to test against your own server. You could, for example, use hunchentoot to easily create a test webserver. Once you have control of the server you can debug both sides of the problem.
Of course, this won't help much if Hunchentoot and the /real/ server behave differently. (See my other email for an example - Hunchentoot knows how to handle chunked transfer encoding used by clients, Apache 1.x doesn't.)
Another way to debug Drakma it to use *HEADER-STREAM* to see at least the headers flying by.
http://weitz.de/drakma/#*header-stream*
Or use something like Ethereal (or whatever it is called nowadays). _______________________________________________ drakma-devel mailing list drakma-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/drakma-devel
On Wed, 14 Feb 2007 16:11:55 -0500, "Andrei Stebakov" lispercat@gmail.com wrote:
For some reason, my gmail client didn't show your messages so the last one was the one from Chris.
Maybe they ended up in the spam folder?
Basically setting :CONTENT-LENGTH T and sending a pathname object instead of string solve the problem. Now I understand that with :CONTENT-LENGTH nil it was sending the chunked data.
Good.
I still don't understand why when I send the request without :CONTENT-LENGTH T and giving a file name starting with p# the lisp process hangs (cmucl), maybe it's just the lisp implementation.
No, I think that's pretty clear: If the server doesn't understand chunked encoding, then Drakma will try to send the file (and it'll only do that if you're using a pathname, i.e. the #P"" syntax), but the server won't accept it - it doesn't know how much it is supposed to read from the stream. So, Drakma tries to send data, but on the other end nobody is reading the data. That's why the whole thing appears to be hanging. You'll probably get a timeout at some point if you wait long enough.
On Mon, 12 Feb 2007 15:44:40 -0500, "Andrei Stebakov" lispercat@gmail.com wrote:
(drakma:http-request "/some/uri" :method :post :form-data t
For file uploads you don't need the ":FORM-DATA T" part.
:parameters `(("Name1" . ,name1) ("Name2" . ,name2) ("File" . ,file-name)))
Without knowing what "/some/uri", NAME1, NAME2, and FILE-NAME are this is hard to say. Is FILE-NAME really a pathname object?
Or maybe the receiving web server can't cope with chunked transfer encoding (like Apache 1.x)? Then you'll have to add
:CONTENT-LENGTH T
to the call, but note that this will force Drakma to compose the whole request body in RAM before sending it which might not work for /very/ large files.
HTH, Edi.
-
Andrei Stebakov -
Chris Dean -
Edi Weitz