it and it may be a good occasion to try
something new.
Hannes
e to nominate John for commit access.
>
>+1
>
>
+1
John has contributed lots of code and energy to the project already. In
fact I asked him if he wanted to be committer when the project moved to
Apache, was too busy with his other work at the time.
Hannes
tin
>
> just realised hannes is from vienna too!
> how's about meeting for a beer? ;-)
Definitely! I thought marmot.at sounded more like western Austria ;-)
Hannes
hannes 02/03/06 07:52:57
Modified:src/java/org/apache/xmlrpc WebServer.java
XmlRpcClientLite.java
Log:
Increased buffer size in readLine() method from 512 to 2048 bytes to
prevent "Header to long" exceptions reported on the users ma
Obviously the 512 byte limit is to short.
Any idea what a good assumption would be for the maximum size of a
single HTTP header?
1k? 2k?
Hannes
Lin, Yaxiong wrote:
>I am getting the "HTTP Header too long" error on the WebServer (running on
>NT) when processing request from t
hannes 02/03/04 07:13:01
Modified:src/java/org/apache/xmlrpc XmlRpcClientLite.java
Log:
Applied fixes from Jim Redman <[EMAIL PROTECTED]> for HTTP keep-alive code.
Due to bugs introduced in the last modification,
° Exceptions that happened when sending the requ
= XmlRpc.getKeepAlive() &&
line.indexOf ("keep-alive") > -1;
so if there is a Connection: header and its value is not "keep-alive",
the keepalive flag is set to false. If there is no Connection: header in
the response, the default value for the minor protocol version is used.
Although I think this code results in the proper behaviour in most
cases, I'd be very interested to hear from people who have better
knowledge of HTTP than me.
Hannes
d be applied in the superclass.
>
> Jim
>
I'm sure this was a problem of the XmlRpcClientLite class only.
XmlRpcClient uses java.net.URLConnection, and even if it should use
keepalive it definitely doesn't put the burden of checking for keepalive
intricacies (like closed connections) on the programmer.
Hannes
call
the server even if the first call actually got through already and the
error occurred somewhere later, e.g. when parsing the response.
thanks,
Hannes
Jim Redman wrote:
> On 2002.02.27 08:43:34 -0700 Hannes Wallnöfer wrote:
>
>> Thanks Jim. One problem I see with your solution i
hannes 02/02/27 10:29:19
Modified:src/java/org/apache/xmlrpc XmlRpcClientLite.java
Log:
Fixed a bug with keepalive connections reported by Jim Redman <[EMAIL PROTECTED]>
A timed out keepalive connection wasn't detected because the exception was thrown
not when try
Thanks Jim. One problem I see with your solution is that it retries on
*every* exception, which is not what we want (or do we?). I'll give it a
try.
Hannes
Jim Redman wrote:
>
> The code in the exception clause of:
>
> public void write (byte[] request) throws I
on the spec will
undermine the core purpose of XML-RPC (interoperability) and hurt
developers. So if the frustrations with core XML-RPC capabilities gets
to big, the solution is to either create a new protocol or go with one
that offers more flexibility (and complexity, I guess) from the start
was only a
proposal, and removing it when it was turned down (not just by Dave
Winer, but also by other members of the XML-RPC community like Eric
Kidd). Sorry about that. But I think it was the right decision to stick
to the spec after all.
Hannes
Chad Ward wrote:
>Would it be possible tha
u can send named parameters within a element, but
the parameter list itself always is an ordered list/array.
In which way does phpgroupware require sending named parameters?
Hannes
[EMAIL PROTECTED] wrote:
>
> hi!
>
> My name is ralph and i just started to experiment with
> t
Just wanted to let you know that I registered the Apache XML-RPC mailing
lists at mail-archive.com.
You can find the developer list archives at
http://www.mail-archive.com/rpc-dev%40xml.apache.org/
and user list at
http://www.mail-archive.com/rpc-user%40xml.apache.org/
Hannes
t;that it would be correct).
>
Yes. For a moment I had thought we could still have universal
compatibility (well, close to universal ;-) without Content-Length
header, but since this is obviously not the case I agree it's a bad idea
to go that way.
Hannes
scription "Java
>>>implementation of XML-RPC, a popular protocol that uses XML over HTTP
>>>to implement remote procedure calls".
>>>
>>Actually, can the team elect a responsible for it so I can give
>>administrative privileges to him?
>>
>
>
ublic static void setHttpProxy (String host, int port, String auth)
to XmlRpcClient.
Hannes
Martin Skopp wrote:
> Thanks for the solution Olivier,
>
> but on the other hand - shouldn't your "XmlRpcClientPlus" class
> somehow go into the release?
>
> IMHO,
k it would be a good idea to offer
methods for an optional stream-based interface to XmlRpcServer.
Hannes
Daniel Rall wrote:
>When the XmlRpcServer class responds to requests, all the data in the
>response is first buffered in memory in whatever form is reasonable
>for output (such as
19 matches
Mail list logo
