On Sun, 2011-04-03 at 08:22 -0700, Ken Krugler wrote: > On Apr 3, 2011, at 8:14am, Sam Crawford wrote: > > > Steve, > > > > I've had a dig around the code this afternoon and understand the > > issues you've run into. The java.net.URI class is fairly well embedded > > throughout, and overriding HttpRequestBase.getRequestLine() alone will > > not be enough. > > > > One thought: Have you considered copying and modifying the source for > > java.net.URI to not throw the URISyntaxException? (Sadly you can't > > just extend it, as it's declared final). Patching HttpClient / > > HttpCore to use your new class would be very straightforward. > > > > You can take a look at some source for java.net.URI at > > http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/java/net/URI.java/?v=source > > Oddly enough, I was just looking at the same thing. > > I'd run into a similar issue, though with hostnames that are allowed by DNS > servers but rejected by URI (e.g. "-sub.domain.com") > > One issue I notice is that you might need to handle is having these query > parameters re-encoded when say URI.toURL() is called. E.g. > > java.net.URI olduri = new java.net.URI("http", "example.com", null, > "var=<xss>", null); > System.out.println(olduri.toURL()); > > will print out "http://example.com?var=%3Cxss%3E";
Steve, Sam and Ken There are several ways to approach the problem: (1) HttpCore uses plain String to represent request-URIs. If core functionality is enough, one can use just about anything for a request-URI (2) If giving up HttpClient if not an option, as long as a resource can be represented by an java.net.URI instance, one can still convert it to a different representation / format when writing the request out. One would need a custom connection manager with a custom MessageWriter, though. Hope this helps Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
