Re: httpclient dont support ö ?
nun habe ich noch das problem das er kein Dateien mit umlauten versenden kann,z.b Übung1.txt I guess you're talking about the content-disposition header or http-headers with umlauts in general - i think there's no standard for sending them. First, i have to define a http-header to be more like a byte[]-array than a String (in the Java sence). The bytes will have to be interpretated by a Charset like UTF8, ISO8859-1 etc. to become a String on the client-side. MaxOSX might use UTF8, Linux and Windows should use the current locale. So there is no correct way to store a umlaut in a HTTP-header since HttpClient cannot know the Charset that the client will use. The Charset for the Headers and the Charset used for the URL are one of the weaknesses of the HTTP-Protocol. UTF8 may become a standard - but this will surely take a while. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: httpclient dont support ö ?
There are two exceptions to this. One is in the case of the URL query string, the other is for some authentication methods. For more on the query string take a look at http://jakarta.apache.org/commons/httpclient/apidocs/org/apache/commons/httpclient/HttpMethodBase.html#setQueryString(org.apache.commons.httpclient.NameValuePair[]) So where's the sollution? Using UTF-8 for the query-string is neither right nor wrong. The server-side (servlet, perl-script, whatever) may simple use any charset it likes to interpretate the query-string. It is a insufficiency of the HttpClient-API that i cannot specifiy the charset used for the query-string. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: \ in path (instead of /)
http://address:port\path\to\some\file.html It might be worthwhile to allow these slashes to be parsed as if they were /'s. such URLs are totally invalid in my eyes. it's nice that some browsers accept them, but i wouldn't care if HttpClient doesn't. Additional it's farely easy to replace them by yourself. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sockets and Java NIO?
Does HttpClient make use of Java NIO when in a Java 1.4.x context? If not, is there any work being done in this direction? wherefor? it doesn't make sense since reading and writing to the socket is done in the thread, from which the methods are called. NIO would make sense, if the API of HttpClient would be somehow asynchronious. That would mean that you can drop a Job into a Queue and that it's executed in the background. As this is not the case, using NIO doesn't make any sense. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: how to specify HTTP 1.0?
But I can't find out how to actually tell HTTPClient to use HTTP 1.0 instead of HTTP1.1? As far as i remeber HttpMethod m = ...; m.setHttp11(false); - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Does HttpClient decompress compressed HTTP transfers?
It'd be rather easy to wrap the streams in a DeflaterOutputStream or an InflaterInputStream. Of course, due to limitations in Java's deflate compression, one must extend DeflaterOutputStream to allow true stream deflation. The problem with the current implementation is that there is no way to flush a partially deflated stream -- deflate waits until it reaches an optimal spot to actually perform the deflation and do the flush. I was talking about decompression downloads. flush() would only be needed to compress POST or PUT requests and that may be poorly supported. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HttpMethodBase.releaseConnection() finished download
Adding the ability to abort methods is planned for the 2.1 release, but I don't think anyone has begun work on it yet. If you come up with a good solution that you are willing to submit we would be happy to make use of it. So what would you suggest how an abort should look like? For me, a boolean paramter for the releaseConnection-method would be sufficient. (releaseConnection() would be a shortcut to releaseConnection(boolean) than). I need this now, so i would try to implement a patch. ´ Well, i had a short look at the source. Beside that the call to releaseConnection() is delegeted from one Class to another, i cannot find the place where the InputStream is read until EOF and i cannot imagine how i should avoid it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cookies, Chunked-Post Threads
browsers make requests in parallel for *one* user! Meaning that all the cookies returned end up in the same cookie store, as they do here. A proxy servlet will make requests for different users (browsers) and therefore has to maintain a different state for each user. That state is typically associated with the session between the browser and servlet. I maintain a HttpState-Object for each Session the Servlet sees. It's either that, or different state objects for each session. But you can't just throw all cookies returned for all users into a single state and expect the HTTP client to figure out which cookie belongs to which user. Sorry, it seems we missunderstood each other. I never wanted to put all in one HttpState-Object. My intention was to maintain one CookieBox per Session and that's what i do with the HttpState-Objects at the moment. Everything works fine now. Thanks for your help. Sven - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cookies, Chunked-Post Threads
HttpClient.executeMethod
(HostConfiguration, HttpMethod, HttpState)
If you have used the same client from different
threads without specifying different states, that
might be a problem.
Well, i use this method now from different thread with different
HttpStates. I'd like to use even one HttpState-Object from different
threads! Is that possible. I'm doing that right now, but i'm not sure if
the HttpClient-APIs cares about that case.
If not, that would be very easy:
synchronized (state)
{
//get cookie headers
}
//execute HTTP-request
synchronized (state)
{
//put cookie header
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cookies, Chunked-Post Threads
unless you have taken special precautions, the state object is used to store cookies. Using the same state from different threads can mix up the cookies from different clients pretty badly. Once you have the cookie problem solved, there is no issue with using the same state object. I dimly remember seeing some synchronized statements in there. Anyway, except for storing cookies, it is accessed read-only. Well, it's a that odd application of the HttpState-Object since every browser makes multiple requests to a server in parrallel. So this would be a feature i would request. Well, most methods of HttpState seem to be synchronized, but as i already mentioned, it's pretty easy to easy to solve any bad mix-up. What i don't want is to serialize (meaning executing one after another) the HTTP-Requests. I want them to execute in parralel. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
