You are viewing a plain text version of this content. The canonical link for it is here.
Posted to xmlrpc-dev@ws.apache.org by "COHEN, STEVEN M (ATTSI)" <sc...@att.com> on 2007/07/20 04:56:56 UTC
RE: [jira] Updated: (XMLRPC-132) Enabling the ability for the xml-rpc client to redirect requests
I suddenly find that I need this functionality (i.e. redirection
handling) - badly.
Am I correct in assuming that it does not exist in any released version
of Apache XML-RPC? It appears destined for 3.1. When is this release
planned?
Since my need is much too urgent to wait for this release, whenever it
may be coming, what would be the best way to incorporate this fix and
nothing else into my existing copy of XML-RPC 3.0?
-----Original Message-----
From: Andrew Norman [mailto:anorman@piczoinc.com]
Sent: Monday, February 12, 2007 9:00 PM
To: xmlrpc-dev@ws.apache.org
Subject: RE: [jira] Updated: (XMLRPC-132) Enabling the ability for the
xml-rpc client to redirect requests
Should be able to verify in the next day or so. Will let you know how it
goes
-----Original Message-----
From: Jochen Wiedmann (JIRA) [mailto:xmlrpc-dev@ws.apache.org]
Sent: Sunday, February 11, 2007 12:49 PM
To: xmlrpc-auto@ws.apache.org
Subject: [jira] Updated: (XMLRPC-132) Enabling the ability for the
xml-rpc client to redirect requests
[
https://issues.apache.org/jira/browse/XMLRPC-132?page=com.atlassian.jira
.plugin.system.issuetabpanels:all-tabpanel ]
Jochen Wiedmann updated XMLRPC-132:
-----------------------------------
Attachment: redirects.patch
Sorry for the delay, but I am really doing my best to manage my backlog.
Please verify the attached patch, which is based on yours, but
drastically minimizes the impact.
> Enabling the ability for the xml-rpc client to redirect requests
> ----------------------------------------------------------------
>
> Key: XMLRPC-132
> URL: https://issues.apache.org/jira/browse/XMLRPC-132
> Project: XML-RPC
> Issue Type: New Feature
> Components: Source
> Affects Versions: 3.0, 3.1
> Reporter: Andrew Norman
> Fix For: 3.1
>
> Attachments: redirects.patch, XMLRPC-132-patch, XMLRPC-132.zip
>
>
> This modification to the XMLRPCStreamTransport adds a customization
point to determine if the transport needs to redirect the request before
attempting to parse the response from the server. This uses a similar
redirect algorithm as used in the Apache Http client to processing
redirects with a Max limit to prevent a recursive loop.
> The redirect logic itself is implemented in two callback methods
isRedirectRequired() and
> resetClientForRedirect()
> These callback methods are only implemented in the
XmlRpcCommonsTransport which means that the other transport options
won't support redirects (unless they are modified to do this by
implementing these call back methods)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: xmlrpc-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: xmlrpc-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xmlrpc-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: xmlrpc-dev-help@ws.apache.org
Re: [jira] Updated: (XMLRPC-132) Enabling the ability for the xml-rpc client to redirect requests
Posted by Jochen Wiedmann <jo...@gmail.com>.
On 7/20/07, COHEN, STEVEN M (ATTSI) <sc...@att.com> wrote:
> Thanks. But that's not what I was asking. The vendor is claiming that
> their system would have worked fine had we used Apache XML-RPC 2.0
> rather than 3.0. I don't believe it. I find nothing in the current
> state of 2.0 that looks remotely like it handles redirection. Do you
> agree with me?
Yes
--
"Besides, manipulating elections is under penalty of law, resulting in
a preventative effect against manipulating elections.
The german government justifying the use of electronic voting machines
and obviously believing that we don't need a police, because all
illegal actions are forbidden.
http://dip.bundestag.de/btd/16/051/1605194.pdf
---------------------------------------------------------------------
To unsubscribe, e-mail: xmlrpc-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: xmlrpc-dev-help@ws.apache.org
RE: [jira] Updated: (XMLRPC-132) Enabling the ability for the xml-rpc client to redirect requests
Posted by "COHEN, STEVEN M (ATTSI)" <sc...@att.com>.
Thanks. But that's not what I was asking. The vendor is claiming that
their system would have worked fine had we used Apache XML-RPC 2.0
rather than 3.0. I don't believe it. I find nothing in the current
state of 2.0 that looks remotely like it handles redirection. Do you
agree with me?
If we are going to get into patching, it will be based on 3.0, not 2.0.
I have no desire to go back there.
-----Original Message-----
From: Jochen Wiedmann [mailto:jochen.wiedmann@gmail.com]
Sent: Friday, July 20, 2007 1:44 PM
To: xmlrpc-dev@ws.apache.org
Subject: Re: [jira] Updated: (XMLRPC-132) Enabling the ability for the
xml-rpc client to redirect requests
On 7/20/07, COHEN, STEVEN M (ATTSI) <sc...@att.com> wrote:
> We are in a discussion with a vendor who claims that their product
> should handle redirection correctly when used with a client (that's
our
> role here) based on Apache XmlRpc 2.0. I have been staring at the 2.0
> code for a while and I am unable to see anyplace in that code base
where
> redirection requests are handled. As far as I can tell, Apache
XML-RPC
> has not handled redirection until the introduction of this patch after
> 3.0. Can someone tell me if I am correct or point me at why this
would
> not have been a problem with 2.0?
The patch isn't too difficult. It should be quite easy to backport
this patch, or a similar functionality to 2.0, perhaps by subclassing
the commons-httpclient transport.
Jochen
--
"Besides, manipulating elections is under penalty of law, resulting in
a preventative effect against manipulating elections.
The german government justifying the use of electronic voting machines
and obviously believing that we don't need a police, because all
illegal actions are forbidden.
http://dip.bundestag.de/btd/16/051/1605194.pdf
---------------------------------------------------------------------
To unsubscribe, e-mail: xmlrpc-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: xmlrpc-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xmlrpc-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: xmlrpc-dev-help@ws.apache.org
Re: [jira] Updated: (XMLRPC-132) Enabling the ability for the xml-rpc client to redirect requests
Posted by Jochen Wiedmann <jo...@gmail.com>.
On 7/20/07, COHEN, STEVEN M (ATTSI) <sc...@att.com> wrote:
> We are in a discussion with a vendor who claims that their product
> should handle redirection correctly when used with a client (that's our
> role here) based on Apache XmlRpc 2.0. I have been staring at the 2.0
> code for a while and I am unable to see anyplace in that code base where
> redirection requests are handled. As far as I can tell, Apache XML-RPC
> has not handled redirection until the introduction of this patch after
> 3.0. Can someone tell me if I am correct or point me at why this would
> not have been a problem with 2.0?
The patch isn't too difficult. It should be quite easy to backport
this patch, or a similar functionality to 2.0, perhaps by subclassing
the commons-httpclient transport.
Jochen
--
"Besides, manipulating elections is under penalty of law, resulting in
a preventative effect against manipulating elections.
The german government justifying the use of electronic voting machines
and obviously believing that we don't need a police, because all
illegal actions are forbidden.
http://dip.bundestag.de/btd/16/051/1605194.pdf
---------------------------------------------------------------------
To unsubscribe, e-mail: xmlrpc-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: xmlrpc-dev-help@ws.apache.org
Re: [jira] Updated: (XMLRPC-132) Enabling the ability for the xml-rpc client to redirect requests
Posted by Jochen Wiedmann <jo...@gmail.com>.
On 7/20/07, COHEN, STEVEN M (ATTSI) <sc...@att.com> wrote:
> This snapshot site seems to contain only relases up to January 8, 2007
> or so, and this patch came out after that. That seems odd. Can you
> comment on this?
Fixed.
--
"Besides, manipulating elections is under penalty of law, resulting in
a preventative effect against manipulating elections.
The german government justifying the use of electronic voting machines
and obviously believing that we don't need a police, because all
illegal actions are forbidden.
http://dip.bundestag.de/btd/16/051/1605194.pdf
---------------------------------------------------------------------
To unsubscribe, e-mail: xmlrpc-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: xmlrpc-dev-help@ws.apache.org
RE: [jira] Updated: (XMLRPC-132) Enabling the ability for the xml-rpc client to redirect requests
Posted by "COHEN, STEVEN M (ATTSI)" <sc...@att.com>.
This snapshot site seems to contain only relases up to January 8, 2007
or so, and this patch came out after that. That seems odd. Can you
comment on this?
-----Original Message-----
From: Jochen Wiedmann [mailto:jochen.wiedmann@gmail.com]
Sent: Friday, July 20, 2007 12:57 AM
To: xmlrpc-dev@ws.apache.org
Subject: Re: [jira] Updated: (XMLRPC-132) Enabling the ability for the
xml-rpc client to redirect requests
On 7/20/07, COHEN, STEVEN M (ATTSI) <sc...@att.com> wrote:
> Am I correct in assuming that it does not exist in any released
version
> of Apache XML-RPC? It appears destined for 3.1. When is this release
> planned?
>
> Since my need is much too urgent to wait for this release, whenever it
> may be coming, what would be the best way to incorporate this fix and
> nothing else into my existing copy of XML-RPC 3.0?
I suggest, that you use one of the snapshot releases, as available from
http://people.apache.org/repo/m2-snapshot-repository/org/apache/xmlrpc/
Otherwise, the patch is attached to the Jira issue (redirects.patch).
Jochen
--
"Besides, manipulating elections is under penalty of law, resulting in
a preventative effect against manipulating elections.
The german government justifying the use of electronic voting machines
and obviously believing that we don't need a police, because all
illegal actions are forbidden.
http://dip.bundestag.de/btd/16/051/1605194.pdf
---------------------------------------------------------------------
To unsubscribe, e-mail: xmlrpc-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: xmlrpc-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xmlrpc-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: xmlrpc-dev-help@ws.apache.org
RE: [jira] Updated: (XMLRPC-132) Enabling the ability for the xml-rpc client to redirect requests
Posted by "COHEN, STEVEN M (ATTSI)" <sc...@att.com>.
We are in a discussion with a vendor who claims that their product
should handle redirection correctly when used with a client (that's our
role here) based on Apache XmlRpc 2.0. I have been staring at the 2.0
code for a while and I am unable to see anyplace in that code base where
redirection requests are handled. As far as I can tell, Apache XML-RPC
has not handled redirection until the introduction of this patch after
3.0. Can someone tell me if I am correct or point me at why this would
not have been a problem with 2.0?
Thanks
-----Original Message-----
From: Jochen Wiedmann [mailto:jochen.wiedmann@gmail.com]
Sent: Friday, July 20, 2007 12:57 AM
To: xmlrpc-dev@ws.apache.org
Subject: Re: [jira] Updated: (XMLRPC-132) Enabling the ability for the
xml-rpc client to redirect requests
On 7/20/07, COHEN, STEVEN M (ATTSI) <sc...@att.com> wrote:
> Am I correct in assuming that it does not exist in any released
version
> of Apache XML-RPC? It appears destined for 3.1. When is this release
> planned?
>
> Since my need is much too urgent to wait for this release, whenever it
> may be coming, what would be the best way to incorporate this fix and
> nothing else into my existing copy of XML-RPC 3.0?
I suggest, that you use one of the snapshot releases, as available from
http://people.apache.org/repo/m2-snapshot-repository/org/apache/xmlrpc/
Otherwise, the patch is attached to the Jira issue (redirects.patch).
Jochen
--
"Besides, manipulating elections is under penalty of law, resulting in
a preventative effect against manipulating elections.
The german government justifying the use of electronic voting machines
and obviously believing that we don't need a police, because all
illegal actions are forbidden.
http://dip.bundestag.de/btd/16/051/1605194.pdf
---------------------------------------------------------------------
To unsubscribe, e-mail: xmlrpc-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: xmlrpc-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xmlrpc-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: xmlrpc-dev-help@ws.apache.org
Re: [jira] Updated: (XMLRPC-132) Enabling the ability for the xml-rpc client to redirect requests
Posted by Jochen Wiedmann <jo...@gmail.com>.
On 7/20/07, COHEN, STEVEN M (ATTSI) <sc...@att.com> wrote:
> Am I correct in assuming that it does not exist in any released version
> of Apache XML-RPC? It appears destined for 3.1. When is this release
> planned?
>
> Since my need is much too urgent to wait for this release, whenever it
> may be coming, what would be the best way to incorporate this fix and
> nothing else into my existing copy of XML-RPC 3.0?
I suggest, that you use one of the snapshot releases, as available from
http://people.apache.org/repo/m2-snapshot-repository/org/apache/xmlrpc/
Otherwise, the patch is attached to the Jira issue (redirects.patch).
Jochen
--
"Besides, manipulating elections is under penalty of law, resulting in
a preventative effect against manipulating elections.
The german government justifying the use of electronic voting machines
and obviously believing that we don't need a police, because all
illegal actions are forbidden.
http://dip.bundestag.de/btd/16/051/1605194.pdf
---------------------------------------------------------------------
To unsubscribe, e-mail: xmlrpc-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: xmlrpc-dev-help@ws.apache.org
Re: [jira] Updated: (XMLRPC-132) Enabling the ability for the xml-rpc client to redirect requests
Posted by Jochen Wiedmann <jo...@gmail.com>.
On 7/23/07, COHEN, STEVEN M (ATTSI) <sc...@att.com> wrote:
> java.nio.charset.IllegalCharsetNameException:
No, this looks more like an encoding problem. May be, the server uses
non-ascii characters in headers, or something like that.
--
"Besides, manipulating elections is under penalty of law, resulting in
a preventative effect against manipulating elections.
The german government justifying the use of electronic voting machines
and obviously believing that we don't need a police, because all
illegal actions are forbidden.
http://dip.bundestag.de/btd/16/051/1605194.pdf
---------------------------------------------------------------------
To unsubscribe, e-mail: xmlrpc-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: xmlrpc-dev-help@ws.apache.org
RE: [jira] Updated: (XMLRPC-132) Enabling the ability for the xml-rpc client to redirect requests
Posted by "COHEN, STEVEN M (ATTSI)" <sc...@att.com>.
This suggestion works. I will be submitting a bug report with a patch.
-----Original Message-----
From: Jochen Wiedmann [mailto:jochen.wiedmann@gmail.com]
Sent: Monday, July 23, 2007 3:21 PM
To: xmlrpc-dev@ws.apache.org
Subject: Re: [jira] Updated: (XMLRPC-132) Enabling the ability for the
xml-rpc client to redirect requests
On 7/23/07, COHEN, STEVEN M (ATTSI) <sc...@att.com> wrote:
> The second line of the try block is getting the currentURI as a
string,
> which judging by the variable's name (charset), and by the documented
> meaning of the the third parameter of the URI constructor in the third
> line of the catch block, is supposed to represent the name of a
charset.
I see, sorry. What happens, if you replace
String charset = currentUri.getURI();
with
String charset = currentUri.getProtocolCharset();
--
"Besides, manipulating elections is under penalty of law, resulting in
a preventative effect against manipulating elections.
The german government justifying the use of electronic voting machines
and obviously believing that we don't need a police, because all
illegal actions are forbidden.
http://dip.bundestag.de/btd/16/051/1605194.pdf
---------------------------------------------------------------------
To unsubscribe, e-mail: xmlrpc-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: xmlrpc-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xmlrpc-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: xmlrpc-dev-help@ws.apache.org
RE: [jira] Updated: (XMLRPC-132) Enabling the ability for the xml-rpc client to redirect requests
Posted by "COHEN, STEVEN M (ATTSI)" <sc...@att.com>.
I had thought of doing this, and I think it would probably work, but did
you see my earlier email? I question the whole approach of doing
redirection in the XMLRPC layer itself, when the HttpClient layer
already handles this. This could be turned on simply by something like
this (in XmpRpcCommonsTransport - last line of the method is new):
protected void initHttpHeaders(XmlRpcRequest pRequest) throws
XmlRpcClientException {
config = (XmlRpcHttpClientConfig) pRequest.getConfig();
method = new PostMethod(config.getServerURL().toString());
super.initHttpHeaders(pRequest);
if (config.getConnectionTimeout() != 0)
client.getHttpConnectionManager().getParams().setConnectionTimeout(confi
g.getConnectionTimeout());
if (config.getReplyTimeout() != 0)
client.getHttpConnectionManager().getParams().setSoTimeout(config.getCon
nectionTimeout());
method.getParams().setVersion(HttpVersion.HTTP_1_1);
method.setFollowRedirects(true);
}
You might want a more flexible system that left this optional, but you
get the idea. I think that will be a much less problem-prone fix. Does
XML-RPC really want to be responsible for something that it HttpClient's
responsibility? I will try this and let you know. If this doesn't work
the other approach is still available.
-----Original Message-----
From: Jochen Wiedmann [mailto:jochen.wiedmann@gmail.com]
Sent: Monday, July 23, 2007 3:21 PM
To: xmlrpc-dev@ws.apache.org
Subject: Re: [jira] Updated: (XMLRPC-132) Enabling the ability for the
xml-rpc client to redirect requests
On 7/23/07, COHEN, STEVEN M (ATTSI) <sc...@att.com> wrote:
> The second line of the try block is getting the currentURI as a
string,
> which judging by the variable's name (charset), and by the documented
> meaning of the the third parameter of the URI constructor in the third
> line of the catch block, is supposed to represent the name of a
charset.
I see, sorry. What happens, if you replace
String charset = currentUri.getURI();
with
String charset = currentUri.getProtocolCharset();
---------------------------------------------------------------------
To unsubscribe, e-mail: xmlrpc-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: xmlrpc-dev-help@ws.apache.org
Re: [jira] Updated: (XMLRPC-132) Enabling the ability for the xml-rpc client to redirect requests
Posted by Jochen Wiedmann <jo...@gmail.com>.
On 7/23/07, COHEN, STEVEN M (ATTSI) <sc...@att.com> wrote:
> The second line of the try block is getting the currentURI as a string,
> which judging by the variable's name (charset), and by the documented
> meaning of the the third parameter of the URI constructor in the third
> line of the catch block, is supposed to represent the name of a charset.
I see, sorry. What happens, if you replace
String charset = currentUri.getURI();
with
String charset = currentUri.getProtocolCharset();
--
"Besides, manipulating elections is under penalty of law, resulting in
a preventative effect against manipulating elections.
The german government justifying the use of electronic voting machines
and obviously believing that we don't need a police, because all
illegal actions are forbidden.
http://dip.bundestag.de/btd/16/051/1605194.pdf
---------------------------------------------------------------------
To unsubscribe, e-mail: xmlrpc-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: xmlrpc-dev-help@ws.apache.org
RE: [jira] Updated: (XMLRPC-132) Enabling the ability for the xml-rpc client to redirect requests
Posted by "COHEN, STEVEN M (ATTSI)" <sc...@att.com>.
I don't think I made myself clear. Let me try again
try {
currentUri = method.getURI();
String charset = currentUri.getURI();
redirectUri = new URI(location, true, charset);
method.setURI(redirectUri);
} catch (URIException ex) {
throw new XmlRpcException(ex.getMessage(), ex);
}
The second line of the try block is getting the currentURI as a string,
which judging by the variable's name (charset), and by the documented
meaning of the the third parameter of the URI constructor in the third
line of the catch block, is supposed to represent the name of a charset.
-----Original Message-----
From: Jochen Wiedmann [mailto:jochen.wiedmann@gmail.com]
Sent: Monday, July 23, 2007 2:08 PM
To: xmlrpc-dev@ws.apache.org
Subject: Re: [jira] Updated: (XMLRPC-132) Enabling the ability for the
xml-rpc client to redirect requests
On 7/23/07, COHEN, STEVEN M (ATTSI) <sc...@att.com> wrote:
> The second line of the try block is getting the currentURI as a
string,
> which judging by its name is supposed to represent the name of a
> charset.
Far away from that. Think of the URI as the URL. It is more likely,
that the URL, which the server sends contains invalid (non-ascii)
characters.
--
"Besides, manipulating elections is under penalty of law, resulting in
a preventative effect against manipulating elections.
The german government justifying the use of electronic voting machines
and obviously believing that we don't need a police, because all
illegal actions are forbidden.
http://dip.bundestag.de/btd/16/051/1605194.pdf
---------------------------------------------------------------------
To unsubscribe, e-mail: xmlrpc-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: xmlrpc-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xmlrpc-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: xmlrpc-dev-help@ws.apache.org
Re: [jira] Updated: (XMLRPC-132) Enabling the ability for the xml-rpc client to redirect requests
Posted by Jochen Wiedmann <jo...@gmail.com>.
On 7/23/07, COHEN, STEVEN M (ATTSI) <sc...@att.com> wrote:
> The second line of the try block is getting the currentURI as a string,
> which judging by its name is supposed to represent the name of a
> charset.
Far away from that. Think of the URI as the URL. It is more likely,
that the URL, which the server sends contains invalid (non-ascii)
characters.
--
"Besides, manipulating elections is under penalty of law, resulting in
a preventative effect against manipulating elections.
The german government justifying the use of electronic voting machines
and obviously believing that we don't need a police, because all
illegal actions are forbidden.
http://dip.bundestag.de/btd/16/051/1605194.pdf
---------------------------------------------------------------------
To unsubscribe, e-mail: xmlrpc-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: xmlrpc-dev-help@ws.apache.org
RE: [jira] Updated: (XMLRPC-132) Enabling the ability for the xml-rpc client to redirect requests
Posted by "COHEN, STEVEN M (ATTSI)" <sc...@att.com>.
Looking still more deeply into this, I wonder what was the motivation
behind this patch in the first place. The XmlRpcCommonsTransport
depends on Apache Commons HttpClient, which is coded to support
redirection. Redirection seems like something that should more
appropriately be supported at the HTTP layer rather than the XML-RPC
layer. If redirection via the HttpClient implementation was not working
properly, wouldn't the right fix have been either to the HttpClient
itself or to XmlRpc's interface with it, rather than reimplementing
redirection at XmlRpc's level?
-----Original Message-----
From: COHEN, STEVEN M (ATTSI)
Sent: Monday, July 23, 2007 9:13 AM
To: xmlrpc-dev@ws.apache.org
Subject: RE: [jira] Updated: (XMLRPC-132) Enabling the ability for the
xml-rpc client to redirect requests
Looking at it more carefully, how could this code work?
try {
currentUri = method.getURI();
String charset = currentUri.getURI();
redirectUri = new URI(location, true, charset);
method.setURI(redirectUri);
} catch (URIException ex) {
throw new XmlRpcException(ex.getMessage(), ex);
}
The second line of the try block is getting the currentURI as a string,
which judging by its name is supposed to represent the name of a
charset. A redirectURI is constructed using this as a parameter in the
third line of the try block and then it blows up on the fourth line of
the try block because the URI is not a valid charset name. How can this
possibly work?
-----Original Message-----
From: COHEN, STEVEN M (ATTSI)
Sent: Monday, July 23, 2007 8:47 AM
To: xmlrpc-dev@ws.apache.org
Subject: RE: [jira] Updated: (XMLRPC-132) Enabling the ability for the
xml-rpc client to redirect requests
I'm having a problem with using the latest code. This problem occurs
whenever the server returns to the client an HTTP 307 packet that causes
the new resetClientForRedirect() functionality to be invoked. Is there
some sort of configuration issue that could cause this to happen.
java.nio.charset.IllegalCharsetNameException:
at java.nio.charset.Charset.checkName(Charset.java:305)
at java.nio.charset.Charset.lookup(Charset.java:439)
at java.nio.charset.Charset.forName(Charset.java:477)
at
java.lang.StringCoding$DecoderCache.makeDecoder(StringCoding.java:109)
at java.lang.StringCoding$1.run(StringCoding.java:155)
at java.security.AccessController.doPrivileged1(Native Method)
at
java.security.AccessController.doPrivileged(AccessController.java:351)
at
java.lang.StringCoding$DecoderCache.getDecoder(StringCoding.java(Compile
d Code))
at java.lang.StringCoding.getDecoder(StringCoding.java(Inlined Compiled
Code))
at java.lang.StringCoding.decode(StringCoding.java(Compiled Code))
at java.lang.String.<init>(String.java(Compiled Code))
at
org.apache.commons.httpclient.util.EncodingUtil.getString(EncodingUtil.j
ava:163)
at
org.apache.commons.httpclient.util.EncodingUtil.getString(EncodingUtil.j
ava:186)
at org.apache.commons.httpclient.URI.decode(URI.java:1769)
at org.apache.commons.httpclient.URI.decode(URI.java:1723)
at org.apache.commons.httpclient.URI.getHost(URI.java:2770)
at org.apache.commons.httpclient.HttpHost.<init>(HttpHost.java:106)
at
org.apache.commons.httpclient.HttpMethodBase.setURI(HttpMethodBase.java:
276)
at
org.apache.xmlrpc.client.XmlRpcCommonsTransport.resetClientForRedirect(X
mlRpcCommonsTransport.java:177)
at
org.apache.xmlrpc.client.XmlRpcCommonsTransport.writeRequest(XmlRpcCommo
nsTransport.java:229)
at
org.apache.xmlrpc.client.XmlRpcStreamTransport.sendRequest(XmlRpcStreamT
ransport.java:140)
at
org.apache.xmlrpc.client.XmlRpcHttpTransport.sendRequest(XmlRpcHttpTrans
port.java:94)
at
org.apache.xmlrpc.client.XmlRpcClientWorker$1.run(XmlRpcClientWorker.jav
a:77)
at java.lang.Thread.run(Thread.java:570)
-----Original Message-----
From: COHEN, STEVEN M (ATTSI)
Sent: Thursday, July 19, 2007 9:57 PM
To: xmlrpc-dev@ws.apache.org
Subject: RE: [jira] Updated: (XMLRPC-132) Enabling the ability for the
xml-rpc client to redirect requests
I suddenly find that I need this functionality (i.e. redirection
handling) - badly.
Am I correct in assuming that it does not exist in any released version
of Apache XML-RPC? It appears destined for 3.1. When is this release
planned?
Since my need is much too urgent to wait for this release, whenever it
may be coming, what would be the best way to incorporate this fix and
nothing else into my existing copy of XML-RPC 3.0?
-----Original Message-----
From: Andrew Norman [mailto:anorman@piczoinc.com]
Sent: Monday, February 12, 2007 9:00 PM
To: xmlrpc-dev@ws.apache.org
Subject: RE: [jira] Updated: (XMLRPC-132) Enabling the ability for the
xml-rpc client to redirect requests
Should be able to verify in the next day or so. Will let you know how it
goes
-----Original Message-----
From: Jochen Wiedmann (JIRA) [mailto:xmlrpc-dev@ws.apache.org]
Sent: Sunday, February 11, 2007 12:49 PM
To: xmlrpc-auto@ws.apache.org
Subject: [jira] Updated: (XMLRPC-132) Enabling the ability for the
xml-rpc client to redirect requests
[
https://issues.apache.org/jira/browse/XMLRPC-132?page=com.atlassian.jira
.plugin.system.issuetabpanels:all-tabpanel ]
Jochen Wiedmann updated XMLRPC-132:
-----------------------------------
Attachment: redirects.patch
Sorry for the delay, but I am really doing my best to manage my backlog.
Please verify the attached patch, which is based on yours, but
drastically minimizes the impact.
> Enabling the ability for the xml-rpc client to redirect requests
> ----------------------------------------------------------------
>
> Key: XMLRPC-132
> URL: https://issues.apache.org/jira/browse/XMLRPC-132
> Project: XML-RPC
> Issue Type: New Feature
> Components: Source
> Affects Versions: 3.0, 3.1
> Reporter: Andrew Norman
> Fix For: 3.1
>
> Attachments: redirects.patch, XMLRPC-132-patch, XMLRPC-132.zip
>
>
> This modification to the XMLRPCStreamTransport adds a customization
point to determine if the transport needs to redirect the request before
attempting to parse the response from the server. This uses a similar
redirect algorithm as used in the Apache Http client to processing
redirects with a Max limit to prevent a recursive loop.
> The redirect logic itself is implemented in two callback methods
isRedirectRequired() and
> resetClientForRedirect()
> These callback methods are only implemented in the
XmlRpcCommonsTransport which means that the other transport options
won't support redirects (unless they are modified to do this by
implementing these call back methods)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: xmlrpc-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: xmlrpc-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xmlrpc-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: xmlrpc-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xmlrpc-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: xmlrpc-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xmlrpc-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: xmlrpc-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xmlrpc-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: xmlrpc-dev-help@ws.apache.org
RE: [jira] Updated: (XMLRPC-132) Enabling the ability for the xml-rpc client to redirect requests
Posted by "COHEN, STEVEN M (ATTSI)" <sc...@att.com>.
Looking at it more carefully, how could this code work?
try {
currentUri = method.getURI();
String charset = currentUri.getURI();
redirectUri = new URI(location, true, charset);
method.setURI(redirectUri);
} catch (URIException ex) {
throw new XmlRpcException(ex.getMessage(), ex);
}
The second line of the try block is getting the currentURI as a string,
which judging by its name is supposed to represent the name of a
charset. A redirectURI is constructed using this as a parameter in the
third line of the try block and then it blows up on the fourth line of
the try block because the URI is not a valid charset name. How can this
possibly work?
-----Original Message-----
From: COHEN, STEVEN M (ATTSI)
Sent: Monday, July 23, 2007 8:47 AM
To: xmlrpc-dev@ws.apache.org
Subject: RE: [jira] Updated: (XMLRPC-132) Enabling the ability for the
xml-rpc client to redirect requests
I'm having a problem with using the latest code. This problem occurs
whenever the server returns to the client an HTTP 307 packet that causes
the new resetClientForRedirect() functionality to be invoked. Is there
some sort of configuration issue that could cause this to happen.
java.nio.charset.IllegalCharsetNameException:
at java.nio.charset.Charset.checkName(Charset.java:305)
at java.nio.charset.Charset.lookup(Charset.java:439)
at java.nio.charset.Charset.forName(Charset.java:477)
at
java.lang.StringCoding$DecoderCache.makeDecoder(StringCoding.java:109)
at java.lang.StringCoding$1.run(StringCoding.java:155)
at java.security.AccessController.doPrivileged1(Native Method)
at
java.security.AccessController.doPrivileged(AccessController.java:351)
at
java.lang.StringCoding$DecoderCache.getDecoder(StringCoding.java(Compile
d Code))
at java.lang.StringCoding.getDecoder(StringCoding.java(Inlined Compiled
Code))
at java.lang.StringCoding.decode(StringCoding.java(Compiled Code))
at java.lang.String.<init>(String.java(Compiled Code))
at
org.apache.commons.httpclient.util.EncodingUtil.getString(EncodingUtil.j
ava:163)
at
org.apache.commons.httpclient.util.EncodingUtil.getString(EncodingUtil.j
ava:186)
at org.apache.commons.httpclient.URI.decode(URI.java:1769)
at org.apache.commons.httpclient.URI.decode(URI.java:1723)
at org.apache.commons.httpclient.URI.getHost(URI.java:2770)
at org.apache.commons.httpclient.HttpHost.<init>(HttpHost.java:106)
at
org.apache.commons.httpclient.HttpMethodBase.setURI(HttpMethodBase.java:
276)
at
org.apache.xmlrpc.client.XmlRpcCommonsTransport.resetClientForRedirect(X
mlRpcCommonsTransport.java:177)
at
org.apache.xmlrpc.client.XmlRpcCommonsTransport.writeRequest(XmlRpcCommo
nsTransport.java:229)
at
org.apache.xmlrpc.client.XmlRpcStreamTransport.sendRequest(XmlRpcStreamT
ransport.java:140)
at
org.apache.xmlrpc.client.XmlRpcHttpTransport.sendRequest(XmlRpcHttpTrans
port.java:94)
at
org.apache.xmlrpc.client.XmlRpcClientWorker$1.run(XmlRpcClientWorker.jav
a:77)
at java.lang.Thread.run(Thread.java:570)
-----Original Message-----
From: COHEN, STEVEN M (ATTSI)
Sent: Thursday, July 19, 2007 9:57 PM
To: xmlrpc-dev@ws.apache.org
Subject: RE: [jira] Updated: (XMLRPC-132) Enabling the ability for the
xml-rpc client to redirect requests
I suddenly find that I need this functionality (i.e. redirection
handling) - badly.
Am I correct in assuming that it does not exist in any released version
of Apache XML-RPC? It appears destined for 3.1. When is this release
planned?
Since my need is much too urgent to wait for this release, whenever it
may be coming, what would be the best way to incorporate this fix and
nothing else into my existing copy of XML-RPC 3.0?
-----Original Message-----
From: Andrew Norman [mailto:anorman@piczoinc.com]
Sent: Monday, February 12, 2007 9:00 PM
To: xmlrpc-dev@ws.apache.org
Subject: RE: [jira] Updated: (XMLRPC-132) Enabling the ability for the
xml-rpc client to redirect requests
Should be able to verify in the next day or so. Will let you know how it
goes
-----Original Message-----
From: Jochen Wiedmann (JIRA) [mailto:xmlrpc-dev@ws.apache.org]
Sent: Sunday, February 11, 2007 12:49 PM
To: xmlrpc-auto@ws.apache.org
Subject: [jira] Updated: (XMLRPC-132) Enabling the ability for the
xml-rpc client to redirect requests
[
https://issues.apache.org/jira/browse/XMLRPC-132?page=com.atlassian.jira
.plugin.system.issuetabpanels:all-tabpanel ]
Jochen Wiedmann updated XMLRPC-132:
-----------------------------------
Attachment: redirects.patch
Sorry for the delay, but I am really doing my best to manage my backlog.
Please verify the attached patch, which is based on yours, but
drastically minimizes the impact.
> Enabling the ability for the xml-rpc client to redirect requests
> ----------------------------------------------------------------
>
> Key: XMLRPC-132
> URL: https://issues.apache.org/jira/browse/XMLRPC-132
> Project: XML-RPC
> Issue Type: New Feature
> Components: Source
> Affects Versions: 3.0, 3.1
> Reporter: Andrew Norman
> Fix For: 3.1
>
> Attachments: redirects.patch, XMLRPC-132-patch, XMLRPC-132.zip
>
>
> This modification to the XMLRPCStreamTransport adds a customization
point to determine if the transport needs to redirect the request before
attempting to parse the response from the server. This uses a similar
redirect algorithm as used in the Apache Http client to processing
redirects with a Max limit to prevent a recursive loop.
> The redirect logic itself is implemented in two callback methods
isRedirectRequired() and
> resetClientForRedirect()
> These callback methods are only implemented in the
XmlRpcCommonsTransport which means that the other transport options
won't support redirects (unless they are modified to do this by
implementing these call back methods)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: xmlrpc-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: xmlrpc-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xmlrpc-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: xmlrpc-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xmlrpc-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: xmlrpc-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xmlrpc-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: xmlrpc-dev-help@ws.apache.org
RE: [jira] Updated: (XMLRPC-132) Enabling the ability for the xml-rpc client to redirect requests
Posted by "COHEN, STEVEN M (ATTSI)" <sc...@att.com>.
I'm having a problem with using the latest code. This problem occurs
whenever the server returns to the client an HTTP 307 packet that causes
the new resetClientForRedirect() functionality to be invoked. Is there
some sort of configuration issue that could cause this to happen.
java.nio.charset.IllegalCharsetNameException:
at java.nio.charset.Charset.checkName(Charset.java:305)
at java.nio.charset.Charset.lookup(Charset.java:439)
at java.nio.charset.Charset.forName(Charset.java:477)
at
java.lang.StringCoding$DecoderCache.makeDecoder(StringCoding.java:109)
at java.lang.StringCoding$1.run(StringCoding.java:155)
at java.security.AccessController.doPrivileged1(Native Method)
at
java.security.AccessController.doPrivileged(AccessController.java:351)
at
java.lang.StringCoding$DecoderCache.getDecoder(StringCoding.java(Compile
d Code))
at java.lang.StringCoding.getDecoder(StringCoding.java(Inlined Compiled
Code))
at java.lang.StringCoding.decode(StringCoding.java(Compiled Code))
at java.lang.String.<init>(String.java(Compiled Code))
at
org.apache.commons.httpclient.util.EncodingUtil.getString(EncodingUtil.j
ava:163)
at
org.apache.commons.httpclient.util.EncodingUtil.getString(EncodingUtil.j
ava:186)
at org.apache.commons.httpclient.URI.decode(URI.java:1769)
at org.apache.commons.httpclient.URI.decode(URI.java:1723)
at org.apache.commons.httpclient.URI.getHost(URI.java:2770)
at org.apache.commons.httpclient.HttpHost.<init>(HttpHost.java:106)
at
org.apache.commons.httpclient.HttpMethodBase.setURI(HttpMethodBase.java:
276)
at
org.apache.xmlrpc.client.XmlRpcCommonsTransport.resetClientForRedirect(X
mlRpcCommonsTransport.java:177)
at
org.apache.xmlrpc.client.XmlRpcCommonsTransport.writeRequest(XmlRpcCommo
nsTransport.java:229)
at
org.apache.xmlrpc.client.XmlRpcStreamTransport.sendRequest(XmlRpcStreamT
ransport.java:140)
at
org.apache.xmlrpc.client.XmlRpcHttpTransport.sendRequest(XmlRpcHttpTrans
port.java:94)
at
org.apache.xmlrpc.client.XmlRpcClientWorker$1.run(XmlRpcClientWorker.jav
a:77)
at java.lang.Thread.run(Thread.java:570)
-----Original Message-----
From: COHEN, STEVEN M (ATTSI)
Sent: Thursday, July 19, 2007 9:57 PM
To: xmlrpc-dev@ws.apache.org
Subject: RE: [jira] Updated: (XMLRPC-132) Enabling the ability for the
xml-rpc client to redirect requests
I suddenly find that I need this functionality (i.e. redirection
handling) - badly.
Am I correct in assuming that it does not exist in any released version
of Apache XML-RPC? It appears destined for 3.1. When is this release
planned?
Since my need is much too urgent to wait for this release, whenever it
may be coming, what would be the best way to incorporate this fix and
nothing else into my existing copy of XML-RPC 3.0?
-----Original Message-----
From: Andrew Norman [mailto:anorman@piczoinc.com]
Sent: Monday, February 12, 2007 9:00 PM
To: xmlrpc-dev@ws.apache.org
Subject: RE: [jira] Updated: (XMLRPC-132) Enabling the ability for the
xml-rpc client to redirect requests
Should be able to verify in the next day or so. Will let you know how it
goes
-----Original Message-----
From: Jochen Wiedmann (JIRA) [mailto:xmlrpc-dev@ws.apache.org]
Sent: Sunday, February 11, 2007 12:49 PM
To: xmlrpc-auto@ws.apache.org
Subject: [jira] Updated: (XMLRPC-132) Enabling the ability for the
xml-rpc client to redirect requests
[
https://issues.apache.org/jira/browse/XMLRPC-132?page=com.atlassian.jira
.plugin.system.issuetabpanels:all-tabpanel ]
Jochen Wiedmann updated XMLRPC-132:
-----------------------------------
Attachment: redirects.patch
Sorry for the delay, but I am really doing my best to manage my backlog.
Please verify the attached patch, which is based on yours, but
drastically minimizes the impact.
> Enabling the ability for the xml-rpc client to redirect requests
> ----------------------------------------------------------------
>
> Key: XMLRPC-132
> URL: https://issues.apache.org/jira/browse/XMLRPC-132
> Project: XML-RPC
> Issue Type: New Feature
> Components: Source
> Affects Versions: 3.0, 3.1
> Reporter: Andrew Norman
> Fix For: 3.1
>
> Attachments: redirects.patch, XMLRPC-132-patch, XMLRPC-132.zip
>
>
> This modification to the XMLRPCStreamTransport adds a customization
point to determine if the transport needs to redirect the request before
attempting to parse the response from the server. This uses a similar
redirect algorithm as used in the Apache Http client to processing
redirects with a Max limit to prevent a recursive loop.
> The redirect logic itself is implemented in two callback methods
isRedirectRequired() and
> resetClientForRedirect()
> These callback methods are only implemented in the
XmlRpcCommonsTransport which means that the other transport options
won't support redirects (unless they are modified to do this by
implementing these call back methods)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: xmlrpc-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: xmlrpc-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xmlrpc-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: xmlrpc-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xmlrpc-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: xmlrpc-dev-help@ws.apache.org