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
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://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
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
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:
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
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
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
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
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
10 matches
Mail list logo