Michael Becke wrote:
We allow a 0 timeout indicating an infinite wait. This is in fact the
default.
Makes me think of Queen's song who wants to live forever :-)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional
Adrian Sutton wrote:
Sounds quite reasonable. The other thing to consider is exactly how
much the URI classes are likely to change anyway. They pretty much do
what's required now and I find it hard to imagine there'd be too many
changes that need to be made.
Code can always be nicer and more
Michael,
Could you please post a wirelog of the session in question? Please refer
to the logging guide on the HttpClient website to learn how to get a log.
Odi
Michael Mattox wrote:
I get a HttpConnection.ConnectionTimeoutException with a certain site
(http://www.fnac.com) but I don't get it
Michael Mattox wrote:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16729
Michael,
We are aware of the problem. The problem is caused by a design flaw
which can not be overcome in the current version. We can not do anything
until we have branched 2.0 out and start working on 2.1. There is a
I think it's easier to create a custom FilePartSource implementation
which creates the events or can be polled by your application.
Odi
Kalnichevski, Oleg wrote:
Jay, The only solution that I can think of is to get hold of
HttpClient source code and extend it with a feedback mechanism of
your
Manuel Castro Paliza wrote:
From NameValuePair to NameValuePair?¿?.
Sorry by my lack of java knowledge but I don't understand this conversion,
is something about memory?.
no. we generally call it bad design, or spaghetti code.
FAQ is good. Improving the API Doc in the spots Om pointed out is even
better.
Odi
Oleg Kalnichevski wrote:
Mike,
Why do not we indeed make a FAQ document out of this Q A session with?
Oleg
-
To unsubscribe, e-mail:
Manuel Castro Paliza wrote:
So finally the cuestion is :
is a Pool of Methods also a High-Level pool of Connections when not using
MultiThreadedHttpConnectionManager ?
No. A method requests a connection from the connection manager on
demand. There is no fix association between a method and a
[www] http://www.nose.ch
ortwin glück [email] [EMAIL PROTECTED]
hardturmstrasse 171 [pgp key] 0x81CF3416
8005 zurich [office] +41-1-277 57 35
switzerland [fax] +41-1-277 57 12
Adrian Sutton wrote:
And if anyone ever works out how a company with just 15 employees winds
up having this much trouble approving one signature I'd love to hear the
explanation... :)
Adrian,
Welcome, man! It's good to have you on board.
Just a few thoughts about the legal noise:
The agreement
Has anybody ever seen a 300 in the wild?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Sunil,
a wirelog would be a lot more interesting.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Adrian Sutton wrote:
I'd also point you to the HTTPS guide but Oleg hasn't written it yet
grin.
There still is the (short) one httpclient/docs/USING_HTTPS.txt
Browse it online here:
Sunil Kumar K wrote:
Should I
need to get the response back and display it OR sending POST message
is enough and browser will get new page from site B.
Sunil,
The user's browser only gets what you write to the ServletOutputStream
of your servlet. This is not an issue with HttpClient. Please
Drake Henderson wrote:
I turned on logging. Looks like I am going to port 80. The url I am using
is for a different port: www.XXX.com: I assumed that the system would
pick the port out of the url.
I don't think so.
-
To
Jeffrey Dever wrote:
I'd say that a post redirect converted to a get is good behaviour to add
as part of the redirect overhaul as discussed for httpclient 3.0
The problem of this scenario is:
- you tell HttpClient to execute a POST
- it is redirected and executes a GET automatically
- but the
wow! I'm deeply impressed.
Odi
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Agreed
(for once)
:-)
Oleg Kalnichevski wrote:
Laura
CPU-bound polling is needed only under fairly unusual circumstances. I
do think that any sort of thread based solution would be an overkill. I
did my best to explain the rationale for not using threads in the bug
report
Cheers
Oleg
[EMAIL PROTECTED] wrote:
waitForResponse should not block infinitely. It should be able to timeout after
given number of ms if no response is forthcoming. If you see a more elegant Java
1.2.2 compatible solution, please advise us
Oleg
There is Object.wait(long) and Object.notify and
Oleg Kalnichevski wrote:
Odi, are you sure you want to have an extra thread per HttpMethod? I do
not think so
Oleg
Better than a busy wait, isn't it?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:
Oleg Kalnichevski wrote:
Mike, certain things in this life cannot be delayed. That includes
patches for rapidly evolving software artifacts in my opinion ;-)
Oleg
I can understand that opinion. On the other hand I think that we should
not loose application developers by changing
Jandalf wrote:
Odi's suggestion of starting a 2.1 branch now is a reasonable one.
Just to make one thing clear. It is a 2.0 branch and not a 2.1 branch I
am talking about:
+-- 2.0 Final
| ¦
CVS
Okay, if I include non-office hours:
9-17h and 20h-23h (which is 10-18h, 21h-24h MET=GMT+1)
Ortwin Glück wrote:
9-16h GMT (which is 10-17h MET=GMT+1)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail
Eric E Johnson wrote:
As for why these functions exist, I keep thinking along these lines -
imagine you want to encode foreign language characters in a URL. The
way to do it is to convert your string into bytes, and then URL encode
the bytes as if it were ASCII. Reversing the process, take
[EMAIL PROTECTED] wrote:
Actually, any sane cgi script or servlet *should* ignore
Content-Length when parsing multipart/form-data request body.
I don't agree. You are mixing protocol and data.
Content-Length is a HTTP protocol element whereas multipart MIME is a
content format.
+1
Very much appreciated.
Oleg Kalnichevski wrote:
Something like root/src/contrib, which
would contain a package named org.apache.commons.httpclient.contrib or
something similar. This package would not be officially maintained. It
would not be included into neither BIN nor SRC distribution,
Max Voelkel wrote:
- a Cache (mentioned a while ago on the list)
- Proxy-Detection
okay
- Some kind of User-Agent on top of HttpClient which:
- handles Framesets (return urls of subframes)
- possibly parses FORM-Tags
- eventually handles JavaScript-Code and
return
+1
I do fully support Jeff's words!
Ortwin Glück
Jeffrey Dever wrote:
Mike Becke has been an active contributor for many months. He has
worked on a diverse range of problems with high quality results. He has
been consistant, reliable, helpful and open to ideas and criticism
Daniel Walsh wrote:
I was under the impression, though, that the implementation that you spoke
of would require an HTML form, or some other type of UI - which my
application does not use. Is that not true?
No of course not. HttpClient provides all you need to tailor an
appropriate POST
Jeffrey Dever wrote:
I'd like to propose an alpha3 build.
+1
This is excellent. There have been many bug fixes gone into CVS since
the alpha2. People helping in testing will like the new release.
Odi
-
To unsubscribe,
If a Transfer-Encoding: chunked header is present, the body must at
least contain the last chunk, which is:
0CRLF
CRLF
Without the last chunk beeing present we can not detect if there is a
body at all! The last chunk not beeing present violates the RFC:
last-chunk has no asterix in front of
Jim Crossley wrote:
I'm on Linux, but I'm not at all familiar with packet sniffing tools,
and I don't really have the time to learn before tomorrow, after which
access to the IIS server will be gone. If someone would kindly post
some commands/options for getting Oleg's data, I'll be happy to try
Thanks Laura for this excellent explanation. This really helps to clear
things up! I am glad to have you and your indepth Unicode knowledge on
the list.
I always thought you could roundtrip any charset to Unicode and get the
same thing back. This is obviously wrong. It should be easy to write
Sung-Gu wrote:
I don't think it's not mature... :(
They have couple of issues still, as I know.. just not revealed yet.
At least they have reached Alpha status! This is more than enough for a
real commons sub-project outside the sandbox.
Sung-Gu wrote:
There isn't any uni-one to support the various charsets.(Let you regard it!)
Then, once it was tranformed, it should be tranformed back to the original.
That makes the transformed one to the original one.
Sung-Gu,
I have problems understanding your English and I can only guess
Sung-Gu wrote:
- Original Message -
From: Ortwin Glück [EMAIL PROTECTED]
Arrrg... again... :(
Not surprising though... :(((
Sung-Gu, I don't want to upset you. I just want to understand the
problem that you are trying to solve with toUsingCharset. Your
explanations did not help so
[EMAIL PROTECTED] wrote:
RFC 2616 does not seem to say much. So, I assume that the default
scheme applies: whatever charset is specified in Content-Type
header. If charset is not explicitly set, ISO-8859-1 is used per
default.
I guess this is the way to go for POST. But what about GET? There is
Alan Marcinkowski wrote:
I found HttpMethodBase:checkValidRedirect was not honoring
cross server redirects. Isn't this a common type of redirect? Is there
a reason its not supported? [...] unless its an architectural issue [...]
Alan,
unfortunately that is an architectural issue currently.
Mike Moran wrote:
Ah, yes, that is a point. I suspect JNDI will be rather too much
overhead for a simple host lookup, but it's worth a look. Async lookups
may also still be impossible.
I don't see much overhead. The only expensive call is the service
lookup. After that the performance fully
301 - 339 of 339 matches
Mail list logo
