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:[EMAIL PROTECTED]
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:[EMAIL PROTECTED]
Sent: Sunday, February 11, 2007 12:49 PM
To: [EMAIL PROTECTED]
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
