Jeff,
(nice to hear from you BTW)
Sung-Gu has basically done all the work on URI related classes. He was
quite active when I joined the project (proxy and SSL patches,
remember?) Last I heard from him was when we had a major argument about
a method that messed with encodings and he was
To make it easier for us, we could even have people compose and maintain
their own list of contributions.
Ortwin Glück wrote:
Yes, let's just put together that 'thank you' page (think of it like the
credits of movie). The question is if we just want to list the names or
if we actually want
Eric Mckenna wrote:
but when opened the encoding is all wrong.
The data is there but No Alderan
Could you be more specific about this please? What do you mean?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands,
the email archive of this list to find the solution or ask the guys over
at FileUpload.
Cheers
Ortwin Glück
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Bruce McHaffie wrote:
It even parses
proxy.pac files correctly.
I guess the browser parses the proxy.pac, not the Sun classes. AFAIK
proxy.pac is written in JavaScript. That's the reason why HttpClient
does not try to interprete proxy.pac files. Maybe one can use Rhino at
some point to do
Oh, there seems to be a lack of documentation on this. Actually a
TimeoutController.TimeoutException extends java.lang.Exception
from the o.a.c.h.util package will be thrown. Timeouts are managed by
the TimeoutController class.
HTH
Ortwin Glück
McMahon, Joseph wrote:
Ok, do you know what
Ortwin Glück wrote:
Oh, there seems to be a lack of documentation on this. Actually a
TimeoutController.TimeoutException extends java.lang.Exception
from the o.a.c.h.util package will be thrown. Timeouts are managed by
the TimeoutController class.
HTH
Ortwin Glück
I have to correct myself
Oleg Kalnichevski wrote:
I'll be away for a week snowboarding in the Swiss Alps (Laax).
Relax, have a lot of fun, enjoy sun, snow and après ski and don't bother
about work too much (bad for your health) :-) Laax is a great place to
stay! Make sure you check out the Rider's Palace, too.
implements RequestEntity
* class FileRequestEntity implements RequestEntity
etc.
What does everybody think about this?
Odi
--
_
NOSE applied intelligence ag
ortwin glück [www] http://www.nose.ch
software
Kalnichevski, Oleg wrote:
Something similar to SAX InputSource would be quite handy I think.
The SAX InputSource was exactly where I got the idea from. But I don't
like the (heavy) way of doing things of that class. I really prefer a
(simple) interface. It is then up to the user how he wants
Roland Weber wrote:
Hello Odi,
is this meant as an extension or as a replacement for
directly passing the InputStream?
It is meant to replace the direct passing of the InputStream. We would
need to remove that method. Deprecation is possible with an internal
wrapper that just throws an
Rezaei, Mohammad A. wrote:
This is a bad idea. The HTTP RFC (2616) explicitly forbids auto retries:
Non-idempotent methods or sequences
MUST NOT be automatically retried, although user agents MAY offer a
human operator the choice of retrying the request(s).
So if retries are not good, then
Rezaei, Mohammad A. wrote:
Both authentication and closed connections should occur long before we read
the input stream to send the request body. So why would you want to reset
the stream?
Thanks
Moh
Well, no.
Authentication failures are only reported by an HTTP status code AFTER
the whole
John Keyes wrote:
My point here is that if I have X requests then there can be
X * CONTENT_LENGTH_CHUNKED
bytes in memory at one time.
I see what you mean. But the above calculation does not make sense:
CONTENT_LENGTH_CHUNKED is a (negative) integer that signals to
HttpClient that you do not
(method);
If you still can not figure out how you can get an InputStream for your
in-memory data, then please refer to other Java resources; but this is
certainly not an issue with HttpClient.
hope that helps
Ortwin Glück
Stefan Dingfelder wrote:
I am missing something here from both views. Maybe I am wrong but as I
understand it, I can provide any InputStream. And that must not be a
file on disk (which I dislike also - except for large files or live
streams that cannot be put to memory in total) but can be any
to
provide your data. Unfortunately HttpClient can not give you the
OutputStream of the underlying socket because of the connection pooling.
Please also note that an unbuffered request can not automatically be
retried.
HTH
Ortwin Glück
Peter Andersén wrote:
Is this the Final 2.0 that support the Final 2.0 API docs ?
What do you think do we include release numbers in jar file names for?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands,
Next week at the Nelson in Zurich. Everyone is invited :-)
Maybe there will be more people than just Oleg and I
keep you posted
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Cheng Hao wrote:
readData() just never returnes
InputStream in = method.getResponseBodyAsStream();
size = readData(in, length);
I guess it's the implementation of readData. Unfortunately its code is
missing, so we can not tell what's going on here.
Fine with me.
Kalnichevski, Oleg wrote:
I feel it is time we cut the final release.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
You seem to be using threads and so I assume you are using the
MultithreadedConnectionManager (you definitely should be!). Oleg just
fixed a bug regarding this issue:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26500
Using the current CVS HEAD (or nightly build) could fix your problem.
Kalnichevski, Oleg wrote:
(1) upgrade to 2.0rc3 release. Better yet, upgrade to the latest CVS HTTPCLIENT_2_0_BRANCH snapshot (which is quite likely to be the 2.0 final). We've just recently fixed a minor bug with socket timeouts in persistent connections. I do not think you are affected by
Carlos,
this is feature request #20288
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20288
[EMAIL PROTECTED] wrote:
I have an issue with an HttpClient where it is executing a PostMethod and I
would like to cancel this method. I have tried to use recycle() and
releaseConnection(), but these
Roland Weber wrote:
As Odi pointed out, you can save the overhead of establishing
a new connection for each request. How much that is depends
on your infrastructure: network latency, authentication overhead,...
Also this means, for a very special applications you can even get more
speed or save
Ram Iyer wrote:
I am using IIS/ServletExec 4.1.1.
Oh dear. The worst server coupled with the maybe worst servlet engine...
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Oleg Kalnichevski wrote:
It
_may_ work, but there are no guarantees.
Means, you should run some decent tests before you make the final decision.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:
Ram Iyer wrote:
Well. That is not in my control. Anyway, is that a problem with httpClient?
It's just a question of how compliant to HTTP standards this combination
of servers is or is not.
-
To unsubscribe, e-mail: [EMAIL
) to be efficient without too much overhead.
Ortwin Glück aka Odi
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Marcus Crafter wrote:
The non-programatic way to fix it was to add a request header to each
client request saying 'Connection: close'.
You could also have written your own connection manager implementation
instead of messing with request headers. This would have been more
portable to later
Kalnichevski, Oleg wrote:
This also affects package naming (org.apache.commons.httpclient vs org.apache.httpclient) which in its turn affects binary compatibility with the previous releases.
Wow cool. Release now under Commons and rename packages later. This
gives us the unique opportunity to
Michael Czeiszperger wrote:
java.lang.ExceptionInInitializerError
Caused by: org.apache.commons.logging.LogConfigurationException:
org.apache.commons.logging.LogConfigurationException: Class
org.apache.comons.logging.impl.Jdk14Logger does not implement Log
This happens when there is an old
[EMAIL PROTECTED] wrote:
--- Additional Comments From [EMAIL PROTECTED] 2004-01-29 12:54 ---
Odi, I think it is a better approach. I especially like the idea to abstract
away all the credentials persistence/retrieval logic. There's one catch,
though. The patch in its current form simply
Maybe you can even alter the overall behaviour. The servlet can fork the
actual work to a new thread and immediately return. Then provide another
servlet that you can poll about the progress of your process.
-
To unsubscribe,
Brad O'Hearne wrote:
The results of this testing has put me into a state of confusion
regarding what httpclient's relationship is to the Java keystore.
I short: There is *no* relationship between HttpClient and the Java
keystore. HttpClient is completely unaware of the underlying SSL
Why not let the servlet send some heartbeats. i.e. every minute send
back some string that informs about the progress or just a simple I am
still alive.
Odi
David Webb wrote:
2) HP-UX / JDK1.4.X - Runs for about 15 minutes then throws the following
exception:
Exception thrown:
is completely unrelated to your question. This is causes more
confusion than it helps.
Your problem: you may want to have a look at the httpd.conf
DirectoryIndex directive.
HTH
Ortwin Glück
Mokwena Motseto wrote:
I have loaded apache on a windows machine, and i am used to working with IIS
i went through
by browsers. HttpClients
design
does not currently allow chaning the method on the fly. That's why you
need to handle this yourself.
Odi
--
_
NOSE applied intelligence ag
ortwin glück [www] http
Catalin Ionescu wrote:
Jan. 09-2003
I use a httpclient to download a file on a daily basis from https website
The site has:
VeriSign International Server CA - Class 3
It was working all 2003 and I have installed httpclient version as Feb. 25th 2003 that was available, but yesterday suddenly
Oleg Kalnichevski wrote:
Folks,
What say you, do we migrate HttpClient issue tracking to JIRA or do we
stay with Bugzilla? Please let me know your opinion.
Oleg
Sorry, I have not had the time to take a look at JIRA and I don't know
that product at all. All I can say is that I am quite familiar
Thanks for your explanation. So I am okay with moving to JIRA. Now is
really a good time, since the number of open bugs is relatively small.
What about existing (old) bugs? Can those be migrated somehow automatically?
Odi
Kalnichevski, Oleg wrote:
Odi,
One nastiest thing about Bugzilla is its
ag
ortwin glück [www] http://www.nose.ch
software engineer [email] [EMAIL PROTECTED]
hardturmstrasse 171 [pgp key] 0x81CF3416
8005 zürich [office] +41-1-277 57 35
switzerland [fax
D Alvarado wrote:
Ok, sorry in advance, I'm sort of a novice at all
of this, but why not? Also, let's just
theoretically say that someone else (not me, of
course), just blindly spit back the response. Is
it possible to tell the client to treat the
response in the context of www.otherdomain.com
encoding basically). But it is very
sensitive to the HTTP headers. It ensures proper transport of the
document between the two ends.
Odi
--
_
NOSE applied intelligence ag
ortwin glück [www] http
Kalnichevski, Oleg wrote:
Plain (non-proxied) host NTLM authentication works fine. I have no access to authenticating NTLM proxy and thus unable to test NTLM proxy authentication.
Feel free to use the local proxy implementation to simulate a request to
a NTLM compliant server.
Kalnichevski, Oleg wrote:
Mike, I can't think of anything better than this hack. Any better ideas?
That's fine with me. I had the same thing in mind. As long as it's only
basic that supports preemtive auth, I see no need for a more
complicated approach. Sometimes you have to be pragmatic...
+0
Sorry, I was out of office for three days...
Odi
Michael Becke wrote:
I propose that we mark the latest code in CVS HTTPCLIENT_2_0_BRANCH as
RC3 and proceed with a release. Please vote as follows:
-
To unsubscribe,
the message body and
therefor does and will not support refresh.
I have been trying to connect to a site (SSL) through our proxy and it send
me back a header with refresh: 0, URL=https://.
and httpclient is not requesting it from there.
Kind regards
Ortwin Glück
Roland Weber wrote:
meta http-equiv=refresh content=0; URL=...
It is common (maybe even standard?) behaviour for browsers to
interpret this meta tag, which does not mean they interpret the
corresponding HTTP header.
Roland,
it may interest you that http-equiv meta parameters are actually meant
Ingo Brunberg wrote:
To work around a bug in the Java VM in this manner seems a bad idea to
me.
When making applications that work on more than one platform and more
than one JDK, working around specific implementation bugs is a very
common problem. I just remeber the drag and drop and
the release plan file from the http client root directory as a source of
information.
Odi
Srinivas Vemula wrote:
Hi,
When are u planning to make the next release??
srini
--
_
NOSE applied intelligence ag
ortwin glück
Kalnichevski, Oleg wrote:
Makes sense. Anyways, some sort of coherent statement with regards to the post-2.0 development directions is pretty much a must for the 2.0 Final. I think I could handle this task while you, guys, concentrate on reviewing the pending patches, even though I am a
Kalnichevski, Oleg wrote:
I hate revisiting the same discussions that raged on this forum 6 months ago, but this is exactly the point. If we decide to go 3.0, then we should stop playing 'bend 2.0 API around' kind of games and should get down to some serious work (which would inevitably delay
Kalnichevski, Oleg wrote:
Version inflation is as evil and misleading, IMHO
Sure. Especially in Java, where Jar-Versioning is a somewhat unsolved
problem (okay you CAN solve it with classloaders but it's a PITA).
Still, you were taling about years :-)
Anyways, why do not we have all HttpClient
Ortwin Glück wrote:
Why not just release the current one as 3.0 and make a 4.0 after that?
What's wrong with that? We all want a release SOON and not within
months. If we make more API changes for 4.0 who cares.
Sorry, I was talking about CVS HEAD here. Forget the SOON
there. But there are quite a few people that
use HttpClient with client certificates subscribed to this list.
HTH
Odi
--
_
NOSE applied intelligence ag
ortwin glück [www] http://www.nose.ch
software engineer
Lionel PASQUIER wrote:
Well... I successfully connected to a https server that does not require certificate with httpClient: the ssl guide explain very well how to do this. But I did not spot anything about client authentication
There is not much.
Maybe I am blind, but I need help! :)
Kalnichevski, Oleg wrote:
Can you give me more details as to why you think this may cause problems with HTTP pipelining?
It won't if done right :-) You just need to make sure that you are
monitoring the response corresponding to the request and not any other
response from previously pipelined
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
Sid Subr wrote:
reason for this mail:
I am having to work with a web server which deos not
understand the 100-continue header and as a result am
having problem uploading large files as the server
closes the connection before the entire content is
transmitted. A change for this has been addressed
-
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
--
_
NOSE applied intelligence ag
ortwin glück
Srinivas Vemula wrote:
We are able to read the stream with
get.getResponseBodyAsStream(). The stream is image bytes delimited by an
ascii string --myboundary, So I guess i just need figure out an easy
way of cutting this stream into bytes for every occurence of that
string.
Just wrap
[EMAIL PROTECTED] wrote:
Version: 2.0 Milestone 2
Isn't M2 a bit dated
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Sid Subr wrote:
Allegro-Software-RomPager/3.10
Sounds like you are programming embedded devices.
Sid, I guess a wire log will keep us from vague guessing.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands,
[EMAIL PROTECTED] wrote:
Browser makers have
gotten a lot of public beating for security bugs lately, and I'd
consider this to be one.
Yep, I guess Safari currently exposes all it's cookies to anyone who
wants to read them :-)
[EMAIL PROTECTED] wrote:
Roland,
I still must have a dormant Sourceforce account. I'll take a closer look at the
Sourceforce login procedure and provide a patch for our browser compatibility
cookie spec if required
Oleg
I also have a SF.net account. If someone would post some code I can run
[EMAIL PROTECTED] wrote:
Unfortunately I do not have access to a NTLM proxy, so this remains to be tested
yet.
Isn't that an excellent occasion to use our new Proxy testing tools?
Can't be too difficult...
-
To unsubscribe,
Kalnichevski, Oleg wrote:
Odi, yes, it is. If someone could post the wirelog of NTLM proxy + basic host authentication as a reference. It is hard to mimic behaviour of a proxy server which you have on access to.
BTW, do you mind using a bit more exotic port number for the proxy testing
Kalnichevski, Oleg wrote:
Odi,
TestProxy#testSimpleGet and TestProxy#testAuthGet fail on me when Tomcat is running
locally and 'httpclient.test.localPort' system property is not set (which is quite
often the case with me). Can we pick just any other less common number per default?
8088?
(HttpClient.java:468)
at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:355)
at org.apache.commons.httpclient.TestProxy.testSimpleGet(TestProxy.java:107)
Can it be that the proxy uses some 1.4 specific methods?
Oleg
-Original Message-
From: Ortwin Glück [mailto
Sid Subr wrote:
the webserver receives the file fine if uploaded from
a web page..
Could be:
- 100 continue handshake problem
- transfer encoding problem
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands,
Roland Weber wrote:
Hello Eric,
it's a question of interpretation, isn't it? If we provide an option to
prefer
Basic auth over NTLM, we violate the RFC. If we provide an option to
*disable* NTLM in certain cases, HttpClient would no longer understand
it, and has to select Basic following the
Sid Subr wrote:
Hi Michael..
did not help..
java.net.SocketException: Software caused connection
abort: socket write error
at
java.net.SocketOutputStream.socketWrite0(Native
Method)
You were saying that everything worked fine for files 3 MB. It seems to me
that your web server limit the
Oleg Kalnichevski wrote:
What's up, folks? I have never seen HttpClient mailing list so quiet for
so long.
My excuse: I had a great time and lots of party in Zurich and I made a
short trip to Barcelona yesterday - thanks to EasyJet :-) My proxy work
should continue this week and I will get
Ortwin Glück wrote:
Normal proxy code is incomplete.
I will use HttpClient to access the server read (buffer) the response
and pass it back to the client. I am not sure how complex the handling
of headers will get and how much we need to implement here...
Odi
Very much appreciated. Is there a reason for the public setters in this
class? I would favour immutable Credentials. I see no point in them
beeing mutable objects, it's not very OO.
Odi
Oleg Kalnichevski wrote:
I think that UserNamePasswordCredentials should not allow null user
name, as well
[EMAIL PROTECTED] wrote:
To test this problem I'm using Apache HTTPD 2.0.40. I tried using Tomcat, but was unable to get it
working with Digest. It seems that Apache uses UTF-8 to encode the user name and password.
Not only does this mean that UTF-8 must be used when calculating the digest, it
Michael Becke wrote:
Mozilla uses UTF-8. I also tried with Safari and Mac IE. Neither of
them work against the Apache digest authentication, so I cannot tell
what they are using.
Mike
I just tried with IE 5.5 on Windows and it returns a strange error
message (DNS error, which seems like a
/
--
_
NOSE applied intelligence ag
ortwin glück [www] http://www.nose.ch
software engineer [email] [EMAIL PROTECTED]
hardturmstrasse 171 [pgp key] 0x81CF3416
8005 zurich [office] +41
oh I see that transfer encoding is taken care of. So ignore the passage
about that in my previous posting. Still we should engange
shouldCloseConnection here because of the difference in HTTP/1.0 and 1.1
-
To unsubscribe,
True.
Klaus, could you provide a wire log that shows the server's response
leading to such a warning? I would just like to check if the warning is
issued correctly. Cheers.
Odi
Kalnichevski, Oleg wrote:
Odi,
In this case I personally think that a warning message is quite appropriate.
Oleg
Varley, Roger wrote:
Hi Khalid
Thanks for the prompt response. Your code produces the follwoing message;
INFO: Already tried to authenticate with 'null' authentication realm at www-proxy2.uk.int.atosorigin.com, but still receiving: HTTP/1.1 407 Proxy Authentication Required ( The ISA Server
Michael Becke wrote:
Odi, Eric,
I think a combination of these techniques would be great. One level to
handle the socket management(as Odi outlined) and another to handle the
content creation/validation (Eric's idea). These two methods in tandem
should be sufficient to mimic any combination
Christian Kohlschütter wrote:
Please have a look at the latest version (see
http://nagoya.apache.org/bugzilla/showattachment.cgi?attach_id=9093
).
It is more abstract than the BadHTTPServer example for Bug 24560 and truly
test independent.
What sort of file is that? It seems binary...
Christian Kohlschütter wrote:
On Tuesday 18 November 2003 11:26, Ortwin Glück wrote:
Christian Kohlschütter wrote:
Please have a look at the latest version (see
http://nagoya.apache.org/bugzilla/showattachment.cgi?attach_id=9093
).
It is more abstract than the BadHTTPServer example for Bug
Christian Kohlschütter wrote:
I own the copyright for this code and I am willing to contribute / publish it
under the conditions of the Apache License.
Thanks a lot!
I will check it in on the 2.0 branch since it is related to a 2.0 bug.
As soon as it is ready we can promote it to CVS HEAD.
There is an option to disable stale checking.
Matthew McGowan wrote:
Any ideas how I go about fixing this?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
Oleg,
I agree, our lack of auth/proxy tests is a continuous source of problems. One of our goals for 2.1
should be an effective method for testing all of the various combinations of proxy, authentication
and SSL. Ideally it would be best to make this setup as simple
Sven Köhler wrote:
If i send the right accept-encoding headers, the web-server may answer
with a gzip or deflate compressed stream. Does HttpClient decompress it?
No, it doesn't.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For
[EMAIL PROTECTED] wrote:
--- Additional Comments From [EMAIL PROTECTED] 2003-11-17 14:38 ---
Odi,
agreed - whitespace is a wrong term. CRLF is better. CRLF or LF is correct ;-)
(see RFC2616, section 19.3).
Would you then prefer my first version of the patch, or do you have another idea
Eric Johnson wrote:
My take is slightly different (and I wish I had time to implement it)
Start by virtualizing the access to the connection, and then, rather
than having multiple servers, just have different implementations of a
virtualized socket interface, for example.
Eric, we can
Sven Köhler wrote:
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
[EMAIL PROTECTED] wrote:
byte bytes[] = new byte[ (n)];
bytes = text.getBytes();
Bravo, the above code couldn't be worse...
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL
Khalid Ishaque wrote:
When I use JDK1.4 every thing works fine, but the second I switch to JDK
1.3.1, I get the java.lang.NoClassDefFoundError:
javax/crypto/NoSuchPaddingException error. Any suggestions???
Please post the stack trace. I am sure this is coming from the
underlying SSL
[EMAIL PROTECTED] wrote:
--- Additional Comments From [EMAIL PROTECTED] 2003-11-13 03:03 ---
Created an attachment (id=9084)
Patch 1
+int[] germanChars = { 0xE4, 0x2D, 0xF6, 0x2D, 0xFc };
+StringBuffer buffer = new StringBuffer();
+for (int i = 0; i
Mike,
in the test case I would rather introduce a Thread.sleep AFTER the
System.gc() call as well to give the GC time to run. GC happens
asynchronously. The System.gc() call is not blocking!
Odi
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24309
--- Additional Comments From [EMAIL
[EMAIL PROTECTED] wrote:
Odi has a point here. There is no reliable way of telling where one response
body ends and another one starts, if content length information is messed up.
That's why the Content-Length header is part of the HTTP 1.1 protocol in
the first place.
[EMAIL PROTECTED] wrote:
Agreed.
In other words, can we assume that reusing the HTTP connection is
unreliable/should be avoided if there are more bytes available than specified
with Content-Length?
In this case, at least, I would suggest to close the current connection and
open a fresh
Christian Kohlschütter wrote:
In this case, at least, I would suggest to close the current connection
and
open a fresh one.
This is the pragmatic way of solving the problem. It always works and is
very reliable. But it is expensive.
btw, what do you mean with expensive?
Expensive: Throwing
Maarten Bodewes wrote:
As HTTP is actually a layer on top of TCP/IP sockets, would it not be
better to be able to provide the HttpClient / HttpConnection with a
socket, or even with an input- and output stream when it is created?
There seems to be no way to create an HTTP session with a socket
101 - 200 of 339 matches
Mail list logo
