Re: \ in path (instead of /)
On Monday 22 December 2003 09:23, Ortwin Glück wrote:
Sam Berlin wrote:
HttpClient (rc2) currently barfs on addresses that look like:
http://address:port\path\to\some\file.html
It might be worthwhile to allow these slashes to be parsed as if they
were /'s.
Why? Sorry, I don't think this sort of URI is defined by any URI RFC
(teach me better). If you need this for your particular application then
please write a convertor for it. But this is certainly not something
that will go into HttpClient.
Odi
Sam,
some time ago, I have also had to work with such backslashed http-URLs.
My solution was to extend the URI class (see below).
It was a quick hack only, but may suit your needs.
Feel free to use/modify the code in your program (feedback always
appreciated).
I agree with Odi that working with backslashes in URIs is unwise and that
support for this should not be included in the HttpClient core (but probably
in contrib someday)
Christian
/**
* A non-standards compliant URI supporting unescaped backslashes ('\')
* and more unwise things
*
* @author Christian Kohlschuetter
*/
public class UnwiseURI extends URI {
public UnwiseURI(String uri) throws URIException {
super(uri, true);
}
public void setRawPath(char[] escapedPath) throws URIException {
if (escapedPath == null || escapedPath.length == 0) {
_opaque = escapedPath;
}
escapedPath = removeFragmentIdentifier(escapedPath);
_path = escapedPath;
setURI();
}
public static void main(String[] args) throws Exception {
System.out.println(new URI(http://www.newsclub.de/foo\\bar;, false));
System.out.println(new UnwiseURI(http://www.newsclub.de/foo\\bar;));
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24352] - NTLM Proxy and basic host authorization
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24352. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24352 NTLM Proxy and basic host authorization --- Additional Comments From [EMAIL PROTECTED] 2003-12-29 14:07 --- ok, thanks a lot :) - especially for being so nice towards someone *this* dumb ;] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [HttpClient] Refactor get/setRequestHeader(Content-Type,..)
Ugh - cross-posting. Seems like this question was meant for httpclient-dev, so I've included that I think the answer will come back from the regulars on the httpclient dev list that the long term intent is to split the request, and response parts of the HttpMethod interface into distinct pieces. As part of those new interfaces, your suggestions certainly make sense. Unfortunately, adding to the existing HttpMethod interface *could* break existing code that doesn't inherit from HttpMethodBase (although as a practical manner, I'm not sure that anyone out there could realistically implement HttpMethod without extending HttpMethodBase, part of its architectural flaw). Defining the constants in some place makes sense, and perhaps those are good utility functions? I think there might be some other subtleties going on here, but I've not really considered this part of the code before. I think various HttpClient commiters are on vacation until Jan., so I wouldn't expect a more complete response before then. -Eric. Gary Gregory wrote: Hello HttpClient, For our code which uses HttpClient, I find myself defining constants and methods in our code for things like Content-Type header handling. I am surprised not to find such a constant in HttpClient in a public place. (It is defined in multipart.Part as protected). I also see a lot of getRequestHeader(Content-Type) and setRequestHeader(Content-Type, ...). This is seem like a good opportunity for a refactoring, in this case to getContentType() and setContentType(String). Is there any reasons these methods do not exist? I am a committer on [lang] and [codec] (also dabbling in [vsf]) and can help out directly or via patches if the group is interested in moving in this direction. Thanks for reading, Gary - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
