- drakma-devel@lists.common-lisp.net - mailman3.common-lisp.net

Re: [drakma-devel] http-request error
by Edi Weitz 03 Mar '11

03 Mar '11

So, I don't have CLISP to test this, but this looks like an incompatibility between CLISP and usocket. If you're using the newest versions of both, I'd suggest that you ask on the usocket mailing list and send a full backtrace. Thanks, Edi. On Mon, Feb 28, 2011 at 7:53 PM, Andre Schütz <andre-paul(a)gmx.de> wrote: > On Mon, 28 Feb 2011 18:06:19 +0100 > Edi Weitz <edi(a)weitz.de> wrote: > >> 2011/2/28 "André Schütz" <Andre-Paul(a)gmx.de>: >> >> > I loaded the drakma system successfully into my clisp environment and got the following error when I tried to make a http-request: >> > >> > (http-request "http://lisp.org/") >> > >> > Fehler: NODELAY in SOCKET-CONNECT is unsupported. >> > >> > Any ideas? >> >> This is the latest Drakma release or the development version? >> >> Also, are you using the newest version of usocket? Which CLISP >> version are you on? Which operating system? >> >> Thanks, >> Edi. > > My configuration is as follows: > > - clisp: GNU CLISP 2.44.1 (2008-02-23) (built 3476003035) > - usocket: 0.4.1 > - Operating System: Ubuntu > > Andre > > > _______________________________________________ > drakma-devel mailing list > drakma-devel(a)common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/drakma-devel > >

1 0

[drakma-devel] http-request error
by "André Schütz" 28 Feb '11

28 Feb '11

Hello, I loaded the drakma system successfully into my clisp environment and got the following error when I tried to make a http-request: (http-request "http://lisp.org/") Fehler: NODELAY in SOCKET-CONNECT is unsupported. Any ideas? Thanks in advance Andre Schütz -- NEU: FreePhone - kostenlos mobil telefonieren und surfen! Jetzt informieren: http://www.gmx.net/de/go/freephone

3 2

[drakma-devel] Failure to load under SBCL on MS Windows 7 (64-bit)
by Duncan Bayne 14 Feb '11

14 Feb '11

Hi All, I'm using Drakma via Quicklisp on SBCL. This works fine under Ubuntu 10.10, but when I attempt to quickload Drakma on MS Windows Ultimate 64-bit, I get 'Error opening shared object "libssl32.dll"'. Here's a REPL session that demonstrates the problem: ===== * (load (merge-pathnames "quicklisp/setup.lisp" (user-homedir-pathname))) T * (ql:quickload '("drakma")) To load "drakma": Load 1 ASDF system: drakma ; Loading "drakma" ................ debugger invoked on a CFFI:LOAD-FOREIGN-LIBRARY-ERROR: Unable to load foreign library (LIBSSL). Error opening shared object "libssl32.dll": 126. Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL. restarts (invokable by number or by possibly-abbreviated name): 0: [RETRY ] Try loading the foreign library again. 1: [USE-VALUE ] Use another library instead. 2: [TRY-RECOMPILING] Recompile reload and try loading it again 3: [RETRY ] Retry loading component ("cl+ssl" "reload"). 4: [ACCEPT ] Continue, treating loading component ("cl+ssl" "reload") as having been successful. 5: [ABORT ] Give up on "drakma" 6: Exit debugger, returning to top level. (CFFI::FL-ERROR "Unable to load foreign library (~A).~% ~A")[:EXTERNAL] 0] ===== I'm quite new to Lisp, but very happy to help in any way necessary (running debug builds, etc.) with tracking this down. Yours, Duncan Bayne

3 4

[drakma-devel] [Patch]: better file-names when sending multipart/form-data from streams.
by Stas Boukarev 21 Jan '11

21 Jan '11

The attached patch does two things: * :filename option takes precedence of automatically determined names (it was the case previously only for pathnames, and not for streams or functions). * if stream is a file-stream, which means it's a pathname designator, use file-namestring to get the filename. -- With Best Regards, Stas.

2 1

[drakma-devel] Patch for disabling SSL in drakma
by Marko Kocić 12 Oct '10

12 Oct '10

Hi all, I'm sending a quick patch to disable CL+SSL dependency, as well as https support in drakma when :drakma-no-ssl feature is present. It works in a similar way as :hunchentoot-no-ssl for hunchentoot. It also added quick info about it in "Download and installation" section of the documentation. The motivation is to be able to use drakma on windows where working libssl32 is not easy to be found. Regards, Marko Kocic

2 1

[drakma-devel] drakma patch: Don't try to funcall keywords
by Faré 28 Sep '10

28 Sep '10

This bit me when updating Drakma. Note that another function in same file uses the same colloquialism as this one: testing if a symbol is fbound before trying to funcall it, otherwise just print it - which works great for keywords. [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Don't forget your daily prayer to Baah-kup, the God of data storage and recovery!

2 1

[drakma-devel] SOCKS5 proxy support
by Red Daly 08 Aug '10

08 Aug '10

I have modified Drakma to use a SOCKS5 proxy if desired. Before I submit a patch I'd like to know what is the preferred interface for this: 1. Modify http-request with a SOCKS-PROXY option analogous to the PROXY option. Introduce SOCKS5 protocol code (about 200 lines) into hunchentoot and rely on no external libraries 2. Modify http-request with a SOCKS-PROXY option analogous to the PROXY option. Introduce a dependency on an external SOCKS5 library. 3. Modify Drakma in some way that allows a user to establish a socks-proxy connection without explicitly supporting this in Drakma itself. The implementation requires that instead of establishing a socket connection to HOST/PORT, the socket connects to SOCKS-HOST/SOCKS-PORT instead and then sets up the socket to forward to HOST/PORT. The implementation is available here: http://github.com/gonzojive/drakma/tree/socks socks5 spec: http://www.faqs.org/rfcs/rfc1928.html Red

2 4

[drakma-devel] New release 1.2.3 [Was: duplicate cookies problem with proposed patch]
by Edi Weitz 05 Aug '10

05 Aug '10

Thanks for the patch. I'm back from vacation now and I've just released 1.2.3 which fixes this. Edi. On Thu, Jul 29, 2010 at 11:22 AM, Vsevolod Dyomkin <vseloved(a)gmail.com> wrote: > Hi, > > I want to re-raise the topic of duplicate cookies. I've had this issue with > the older version of Drakma (1.1.0) and was unaware of the patch with > *remove-duplicate-cookies-p*. > But investigating the problem (before I've read the discussion in the > mailing list), I've encountered it's cause in the source code, that is > highlighted in the attached diff. The problem is, that SET-DIFFERENCE and > UNION are not supplied COOKIE= tests in UPDATE-COOKIES. > > It still remains in the current version (1.2.2) and can be tested like this: > > CL-USER> (defvar *cookies* (make-instance 'drakma:cookie-jar)) > *COOKIES* > CL-USER> (drakma::update-cookies (list (make-instance 'drakma:cookie :name > "lang" :value "en" :domain "site.com" :path "/") > (make-instance 'drakma:cookie :name > "lang" :value "en" :domain "site.com" :path "/")) > *cookies*) > #<DRAKMA:COOKIE-JAR (with 2 cookies) {B629521}> > > I think, that this is a bug, because without the TEST argument, for example, > SET-DIFFERENCE in this case will constantly return the first set (see > below), so either the code should be simplified or the test argument should > be added. > > CL-USER> (set-difference (list (make-instance 'drakma:cookie :name "lang" > :value "en" :domain "site.com" :path "/") > (make-instance 'drakma:cookie :name "lang" > :value "en" :domain "site.com" :path "/")) > (list (make-instance 'drakma:cookie :name "lang" > :value "en" :domain "site.com" :path "/") > (make-instance 'drakma:cookie :name "lang" > :value "en" :domain "site.com" :path "/"))) > (#<DRAKMA:COOKIE lang=en; path=/; domain=site.com> > #<DRAKMA:COOKIE lang=en; path=/; domain=site.com>) > > So, I believe, that this part should also be fixed, especially, since > UPDATE-COOKIES is called alongside with GET-COOKIES. > > Best regards, > Vsevolod > > _______________________________________________ > drakma-devel mailing list > drakma-devel(a)common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/drakma-devel > >

1 0

Re: [drakma-devel] duplicate cookies problem with proposed patch
by Vsevolod Dyomkin 29 Jul '10

29 Jul '10

Hi, I want to re-raise the topic of duplicate cookies. I've had this issue with the older version of Drakma (1.1.0) and was unaware of the patch with *remove-duplicate-cookies-p*. But investigating the problem (before I've read the discussion in the mailing list), I've encountered it's cause in the source code, that is highlighted in the attached diff. The problem is, that SET-DIFFERENCE and UNION are not supplied COOKIE= tests in UPDATE-COOKIES. It still remains in the current version (1.2.2) and can be tested like this: CL-USER> (defvar *cookies* (make-instance 'drakma:cookie-jar)) *COOKIES* CL-USER> (drakma::update-cookies (list (make-instance 'drakma:cookie :name "lang" :value "en" :domain "site.com" :path "/") (make-instance 'drakma:cookie :name "lang" :value "en" :domain "site.com" :path "/")) *cookies*) #<DRAKMA:COOKIE-JAR (with 2 cookies) {B629521}> I think, that this is a bug, because without the TEST argument, for example, SET-DIFFERENCE in this case will constantly return the first set (see below), so either the code should be simplified or the test argument should be added. CL-USER> (set-difference (list (make-instance 'drakma:cookie :name "lang" :value "en" :domain "site.com" :path "/") (make-instance 'drakma:cookie :name "lang" :value "en" :domain "site.com" :path "/")) (list (make-instance 'drakma:cookie :name "lang" :value "en" :domain "site.com" :path "/") (make-instance 'drakma:cookie :name "lang" :value "en" :domain "site.com" :path "/"))) (#<DRAKMA:COOKIE lang=en; path=/; domain=site.com> #<DRAKMA:COOKIE lang=en; path=/; domain=site.com>) So, I believe, that this part should also be fixed, especially, since UPDATE-COOKIES is called alongside with GET-COOKIES. Best regards, Vsevolod

1 0

[drakma-devel] Regarding URL encoding...
by Herbert Snorrason 21 Jul '10

21 Jul '10

Although I understand why it's not done by default, it seems slightly odd to me that Drakma doesn't provide a URL-ENCODE function whereas Hunchentoot does. I would've thought the need was considerably more immediate in Drakma... With greetings, Herbert Snorrason

2 2