- s-xml-rpc-devel@common-lisp.net - mailman3.common-lisp.net

[s-xml-rpc-devel] Fault returned when calling method with no arguments
by Andrew Jones-Gonzales 14 Oct '08

14 Oct '08

I've run into an interesting problem where S-XML-RPC would complain that an "empty" string was not of type LIST. It would only occur when I used S-XML-RPC for just the server. When I used something else as the client, like the command line tool that came with the XML-RPC-C library or the XML-RPC.Net library for C#, the server would return the fault. Using S-XML-RPC as a client worked fine. After some debugging, I think I traced the cause to a few extra #\Newline and #\Return characters getting inserted into the XML from these other libraries/tools. So essentially, they give us a string that should be empty, but instead has whitespace in it. I'm not sure if it's more correct to patch these other libraries instead, but the small patch I'm attaching fixes this in S-XML-RPC. Cheers, -Andrew Jones-Gonzales

1 0

[s-xml-rpc-devel] [PATCH] Interoperability issue with WS-XMLRPC
by Daniel Janus 18 Apr '08

18 Apr '08

Hello, I'm using the current asdf-installable version of S-XML-RPC with SBCL 1.0.15 (hand-compiled from source on an i686) and have been trying to connect with its client API to various XML-RPC servers. It has been mostly working, with only an exception of one server. The server in question is an enterprise Java EE 5 application, written using Apache WS-XMLRPC library (version 3.1 to be more precise) and deployed on a cluster consisting of two Glassfish enterprise server instances, both running on Ubuntu 6.06.1. The problem manifests itself in XML-RPC-CALL -- it bails out with an error "no response from server". I tried another XML-RPC stack (the one that comes with Python) and I had no problems with making the same request to the same server. I did some preliminary investigation and found a workaround to the problem. It seems that building up the whole XML-RPC request beforehand, then sending it all at once (rather than FORMATting the HTTP headers to the TCP stream one-by-one) fixes the problem. This is what the attached patch does. I enclose it just in case someone else runs into the same problem; it works for me, on the downside, it probably causes the library to do more consing, although I did not check that empirically. Strangely enough, the problem does not seem to occur with an installation of the very same Java application on a single (non-clustered) Glassfish running on newer versions of Ubuntu. Clearly, more detailed investigation is required. As soon as I have time for that, I will attempt to reproduce the behaviour on various setups and using various Lisps (I have access to Allegro 8.1), to see where the problem really lies. I hope for attaining a true fix instead of a workaround. I will send a followup as soon as I have more detailed information. Best, -- Daniel Janus <daniel(a)sentivision.com> Senior Software Engineer, SENTIVISION Mb: +48.501180396 | Ph: +48.226400860

2 1

[s-xml-rpc-devel] significant speed increase in SBCL
by William Halliburton 17 Feb '08

17 Feb '08

Hello all. Using s-xml-rpc with SBCL 1.0.14 and was seeing a lot of consing. Just attempted to hit some low hanging fruit and got lucky. Please excuse any wierd table cut-and-paste formatting below. I am using hunchentoot as the front end and was calling as such: (handle-xml-rpc-call (raw-post-data :want-stream t) id) Profiling gave: (note that the lisp test system was calling itself so both the call and answer are shown, but I really only care about the answer.) ;; seconds | consed | calls | sec/call | name ;; ---------------------------------------------------------- ;; 10.430 | 107,109,496 | 32 | 0.325942 | S-XML-RPC:XML-RPC-CALL ;; 5.583 | 57,897,032 | 1,670 | 0.003343 | S-XML::PARSE-IDENTIFIER ;; 1.179 | 12,740,176 | 835 | 0.001412 | S-XML::PARSE-XML-ELEMENT ;; 1.073 | 9,625,512 | 1,845 | 0.000582 | S-XML::PARSE-WHITESPACE ;; 0.988 | 8,591,704 | 239 | 0.004132 | S-XML::PARSE-TEXT ;; 0.425 | 4,491,216 | 899 | 0.000472 | S-XML::SKIP-WHITESPACE ;; 0.111 | 53,968 | 1,670 | 0.000067 | S-XML:RESOLVE-IDENTIFIER ;; 0.041 | 0 | 11,810 | 0.000003 | S-XML::IDENTIFIER-CHAR-P ;; 0.028 | 516,088 | 64 | 0.000436 | S-XML-RPC::FORMAT-HEADER ;; 0.021 | 720 | 1,670 | 0.000013 | S-XML::FIND-NAMESPACE-BINDING ;; 0.021 | 0 | 1,845 | 0.000011 | S-XML::GET-BUFFER ;; 0.013 | 0 | 1,670 | 0.000008 | S-XML:SPLIT-IDENTIFIER ;; 0.011 | 0 | 835 | 0.000013 | S-XML-RPC::DECODE-XML-RPC-FINISH-ELEMENT When I changed handle-xml-rpc-call to take a string as make its own stream as such: (handle-xml-rpc-call-string (raw-post-data) id) (defun handle-xml-rpc-call-string (string id) (with-input-from-string (in string) (let ((call (decode-xml-rpc in))) (let ((result (apply *xml-rpc-call-hook* (first call) (rest call)))) (encode-xml-rpc-result result)))))) I now profile: seconds | consed | calls | sec/call | name --------------------------------------------------------- 0.985 | 15,135,160 | 32 | 0.030786 | S-XML-RPC:XML-RPC-CALL 0.023 | 118,296 | 1,670 | 0.000014 | S-XML:RESOLVE-IDENTIFIER 0.021 | 0 | 11,810 | 0.000002 | S-XML::IDENTIFIER-CHAR-P 0.019 | 769,856 | 32 | 0.000593 | RPC-HANDLER 0.016 | 459,688 | 64 | 0.000248 | S-XML-RPC::FORMAT-HEADER 0.013 | 11,128 | 899 | 0.000014 | S-XML::SKIP-WHITESPACE 0.010 | 12,536 | 1,670 | 0.000006 | S-XML::PARSE-IDENTIFIER 0.009 | 0 | 1,670 | 0.000006 | S-XML::GET-MINI-BUFFER 0.009 | 0 | 1,670 | 0.000006 | S-XML:SPLIT-IDENTIFIER 0.004 | 0 | 8 | 0.000498 | UPDATE-SEARCH-STRING 0.004 | 7,944 | 32 | 0.000118 | S-XML-RPC::ENCODE-XML-RPC-RESULT For a 10 fold speed increase. I just thought this might be of use to someone down the line. Will

2 1

[s-xml-rpc-devel] BUG ?
by Evgeniy Zamriy 15 Feb '08

15 Feb '08

Hello, All. Version of SBCL - 1.0.1 Version of s-xml-rpc - latest from cvs I found possible bug in library: * (decode-xml-rpc (make-string-input-stream "<value><boolean>1</boolean></value>")) * T * (decode-xml-rpc (make-string-input-stream "<value><boolean>0</boolean></value>")) * "" So, when my client resieves "false" from server I get "" except of nil. Is this bug or feature ? :) I tryed to fix it, but my experience in lisp isn't well. P.S.: my english is bad, sorry :) -- Best regards, Evgeniy Zamriy

2 2

[s-xml-rpc-devel] loss of precision on double
by Jeff Sapp 15 Feb '08

15 Feb '08

Hey, I was using s-xml-rpc to receive some double values and I noticed that was losing precision on them. I looked a bit closer and I noticed that the function decode-xml-rpc-new-element was reading in doubles with read-from-string which has a default return type of single-float. I'd still consider myself new at this lisp business, so my fix probably isn't stellar. I've also run into some performance issues and I was wondering if anyone had some advice. The function I'm having particular trouble with returns a list of lists, where the outside list is about 20k elements long, and the inside lists around no larger than 20. It takes about two minutes to encode the whole thing. If you had to make the encoding more efficient, where would you start? Thanks, ~jeff

2 2

[s-xml-rpc-devel] s-xml-rpc simple problem.
by Nicolas Lamirault 18 Feb '07

18 Feb '07

hello, i try to use s-xml-rpc to test the Gandi XML RPC API. In python, there is an example code : import sys import xmlrpclib proxy = xmlrpclib.ServerProxy("https://api.ote.gandi.net/xmlrpc/") try: session = proxy.login("AA1234-GANDI", "mypassword") except xmlrpclib.Fault, e: print "could not login because: " + e.faultString sys.exit(67) it is possible to make this call with s-xml-rpc ? Thanks for any help.

1 0

[s-xml-rpc-devel] SBCL support
by Sebastián González 01 Nov '06

01 Nov '06

Hi there, When I tried the following code from the "test" directory of s-xml-rpc, using SBCL, I got an error: (assert (let ((server-process (start-xml-rpc-server :port 8080))) (import 's-xml-rpc::xml-rpc-implementation-version :s-xml-rpc-exports) (sleep 1) ; give the server some time to come up ;-) (unwind-protect (equal (xml-rpc-call (encode-xml-rpc-call "XML-RPC-IMPLEMENTATION-VERSION") :port 8080) (xml-rpc-implementation-version)) (s-sysdeps:kill-process server-process) (unintern 's-xml-rpc::xml-rpc-implementation-version :s-xml-rpc-exports)))) The error message is the following (copy-pasted from Slime): The value (("xml-rpc server /RPC2:8080" #<SB-BSD-SOCKETS:INET-SOCKET descriptor 4 {B61F4C9}> #<SB-IMPL::HANDLER INPUT on descriptor 4: #>)) is not of type SB-THREAD:THREAD. [Condition of type TYPE-ERROR] Apparently SBCL's implementation of s-sysdeps:start-standard-server is broken... Does this code still have a maintainer? should I fix it myself and submit a patch? Thanks, Sebastián

1 0

[s-xml-rpc-devel] Patch
by Maciek Pasternacki 27 Aug '06

27 Aug '06

Hello. I started to look at s-xml-rpc library today and to communicate with Python client. Python's default xmlrpclib sends no-argument methods like this (from debug log): ,---- | <?xml version='1.0'?> | <methodCall> | <methodName>system.listMethods</methodName> | <params> | </params> | </methodCall>12 received call ("system.listMethods" . " | ") `---- Library throws error from #'APPLY because last argument is a string, not a list. A simple patch that makes it work: #v+ diff -u xml-rpc{-orig,}.lisp --- xml-rpc-orig.lisp 2006-08-27 21:43:19.000000000 +0200 +++ xml-rpc.lisp 2006-08-27 21:43:25.000000000 +0200 @@ -494,6 +494,8 @@ ;; -32603 ---> server error. internal xml-rpc error (encode-xml-rpc-fault (format nil "~a" c) -32603))))) (let ((call (decode-xml-rpc (debug-stream in)))) + (unless (listp (rest call)) + (setf (rest call) nil)) (format-debug (or *xml-rpc-debug-stream* t) "~a received call ~s~%" id call) (let ((result (apply *xml-rpc-call-hook* (first call) #v- -- __ Maciek Pasternacki <maciekp(a)japhy.fnord.org> [ http://japhy.fnord.org/ ] `| _ |_\ / { Ibi nullus timet mortem ,|{-}|}| }\/ sed pro Baccho mittunt sortem. } \/ |____/ ( Carmina Burana ) -><-

1 0

[s-xml-rpc-devel] bug: S-XML-RPC sends unencoded strings with invalid characters
by Taylor R Campbell 28 Jul '06

28 Jul '06

Well-formed XML is not allowed to include character entities that are not legal XML characters, according to the definition of character entity references in section 4.1 of the XML 1.0 specification: [66] CharRef ::= '&#' [0-9]+ ';' | '&#x' [0-9a-fA-F]+ ';' Well-formedness constraint: Legal Character - Characters referred to using character references MUST match the - production for Char. The production for Char is defined in section 2.2: [2] Char ::= #x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] | [#x10000-#x10FFFF] Strings with any other characters ought to be base64-encoded. I just encountered a problem when lisppaste sent an XML-RPC response with a paste that contains form feed characters to client with an extremely strict XML parser.

2 4

[s-xml-rpc-devel] Re: Incorrect decoding of XML RPC messages
by Sven Van Caekenberghe 19 Apr '06

19 Apr '06

On 18 Apr 2006, at 06:56, Alain Picard wrote: > Okay -- I've got a fix which ensures that things > like "<data> </data>" decode as NIL, instead of " ". > > Here are the diffs, in case you want to have a look > and/or fold them in. > > > The gist of it now is that if you're inside a <value>, > you always get a string if the inner type is not specified, > since the spec says: > "If no type is indicated, the type is string." > > Thus "<value></value>" now decodes as "". > > I also fixed what I think is a bug in that > (encode-xml-rpc-value T) ==> "T" instead of <boolean>1</boolean>. > (same for NIL). > > <diff> Alain, I tried to integrate your changes; I didn't take over the special variable: it felt less elegant and I think I managed to solve all your problems without it. I took over most of your code though: thanks! I added a number of extra test cases to test-xml-rpc.lisp to cover all the problems that you reported. Have a look at it and tell me if this works for you. This is the official change log entry (all changes were commit but not yet released as tarball): * changes due to reporting and initial fixes by Alain Picard * added support for whitespace handling * iso8601->universal-time now accepts leading & trailing whitespace * encode-xml-rpc-value now encodes t and nil correctly as boolean 1 and 0 * parsing doubles (using read-from-string) with reader macros disabled for security * decode-xml-rpc now handles whitespace more correctly in <data> and <value> tags * added several test cases and fixed older stop-server problem I enclosed a context diff here for your convenience. Sven

1 0