attachments 100 KB get stripped by the list.
many thanks in advance.
Cheers,
quent
--
_
NOSE applied intelligence ag
[www] http://www.nose.ch
ortwin glück [email] [EMAIL
Adrian Sutton wrote:
On Tuesday, July 22, 2003, at 09:28 AM, Andre Augusto de Oliveira
Aragao wrote:
2003-07-21 18:41:44,472 [main] DEBUG
org.apache.commons.httpclient.HttpClient - SunJCE 1.42: SunJCE Provider
(implements DES, Triple DES, AES, Blowfish, PBE, Diffie-Hellman,
HMAC-MD5,
HMAC-SHA1)
David Sean Taylor wrote:
This implies that I can't contribute the InputStreamPartSource to your
codebase as is, since it will be coupled to my particular InputStream
factory.
Right, because the InputStreamPartSource can (by design) not fulfill the
contract of the createInputStream method
Wow, all that without getting 5$ :-)
[EMAIL PROTECTED] wrote:
--- Additional Comments From [EMAIL PROTECTED] 2003-07-18 13:11 ---
Fair enough. I will provide a test case shortly
Oleg
-
To unsubscribe, e-mail: [EMAIL
Querent,
let me put numbers in front of your actions (just for easier reference):
1. I have already succeed uploading file using MultipartPostMethod.
2. I have to download the file back for future reference.
3. I have already tried downloading the file both using GetMethod and
PostMethod, but
most experience here. Is there anything we must mention?
Odi
--
_
NOSE applied intelligence ag
[www] http://www.nose.ch
ortwin glück [email] [EMAIL PROTECTED
[EMAIL PROTECTED] wrote:
I just decompiled the version 1.6 of the library and indeed, it seems that
this version does not handle status 100 responses, whereas version 2.0
does. I'll upgrade the library and let you know if this helps!!! :-)
Thanks a lot again!
Patrick
Mind the API and behaviour
+1
Michael Becke wrote:
I propose that we start using commons-codec (nightly builds) for our
Base64 and URL encoding needs. This change would go into effect for
the 2.1 release (HEAD).
--
Vote: commons-codec
Adrian Sutton wrote:
+1.
Also +1 for keeping a specific list of files that's required from codec
so that applet developers like me can just pull them out instead of
having the whole kit and kaboodle. I volunteer for such a role.
Adrian Sutton.
Currently Codec consists of 2 (two) classes,
oops, true. No idea why I remembered only two classes...
Kalnichevski, Oleg wrote:
Odi,
I do not think it is quite correct. There's now at least two dozens of files, and some
of them are really of marginal use (language and phonetic encoders, for instance)
Oleg
Christopher Lenz wrote:
just a we'll try to preserve backwards compatibility as much as possible.
May I remind everybody that we made the 2.0 branch so that we can
finally overhaul the architecture. This normally implies large scale API
changes. Maintaining backwards compatibility and doing
Excellent!
Although you are still messing with the encoding of the Source files :-)
Check my name: The ü is now a decomposed Unicode Character in UTF-8. 3
Bytes :-)
- * @author Ortwin Glück
+ * @author Ortwin Gl�ck
[EMAIL PROTECTED] wrote:
It is possible to create a standard JSSE impl, but only for 1.4 JDK. In
previous JDK's the required classes were of the com.sun.net.ssl variety,
which of course is ugly. There is no cross-vm solution for JDKs prior to
1.4 that I am aware of.
- Matt Secoske
Zulfi Umrani wrote:
I will appreciate if anyone answers my questions below.
-Does anyone has perfromance comparison between HTTPClient and JDK
HttpURLConnection?
I remember there was a comment about that on the list some months ago.
The guy said that HttpClient was slightly faster than
Good to here that you are fine! Welcome back to the Fellowship of The
Protocol. I have been missing your insightful comments on the list recently.
Odi
Jandalf wrote:
My house has sold, I've moved to Calgary and I have a new job. All is
well. I've been monitoring the list and have been taking
[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
[EMAIL PROTECTED] wrote:
I am looking for a way to specify a particular
client SSL certificate for Client Authenticated SSL.
This is usually done by writing a SSLSocketFactory that creates Sockets
with the Client Cert attached.
Kalnichevski, Oleg wrote:
I have only one outstanding issue on my hands: deprecation of
URIUtil.toXXXCharset methods.
As far as I remember these methods are not currently used. So they do
not harm. We can address this later if necessary. The whole issue seems
still a bit unclear to me, but
+1
Adrian Sutton wrote:
I move the motion that the following methods from
org.apache.commons.httpclient.util.URIUtil be depreciated for the 2.0
release and removed in a future release:
toDocumentCharset(String)
toDocumentCharset(String, String)
toProtocolCharset(String)
It sure would be useful however I am not sure if it is possible. I never
used a standard JSSE implementation. We used SSLava in our projects
(because it's supposed to be faster) and SSLava is does not have a JSSE
interface. So I wrote a SSLSocketFactory that configured SSLava to use a
specific
Sung-Gu wrote:
But, not a duty... it's voluteering... no pay...
even the code constribution here...
I pay you $5 for test cases from my Paypal account. Promise.
:-)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional
I think we should change the logging guide to set the log level to DEBUG
for org.apache.commons.httpclient. Currently it is set to TRACE and
users seem to leave it like this. Oleg, do you find this TRACE level
bloated logs useful? I think in the majority of cases a DEBUG level
output is
Oleg Kalnichevski wrote:
I fully agree. In 99% cases TRACE log produces no useful information. I
even usually grep through the logs excluding TRACE entries in order to
make them comprehensible.
Oleg
Patch to xdocs applied. The web will reflect the changes when it is next
generated.
Odi
Eric Johnson wrote:
Ortwin,
It is an odd problem. Not quite a dead-lock in the traditional sense.
One thread is waiting on the other, and the other is waiting for the
garbage collector. It just so happens that the garbage collector will
never kick in, because the first thread happens to be
Adrian Sutton wrote:
Odi,
HttpClient doesn't depend on the GC, it depends on the user telling us
when the connection is no longer in use (which Eric discovered he hadn't
done). There is however a fallback whereby when a HttpConnection is
garbage collected (ie: when we discover that it is no
[EMAIL PROTECTED] wrote:
--- Additional Comments From [EMAIL PROTECTED] 2003-06-19 14:54 ---
Are there any objections, comments to this patch?
Oleg
Okay with me. Maybe UPPERCASE the BitSet identifier?
-
To unsubscribe,
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
Oh dear! What have I done... shame on me.
I'll fix that immediately. Sorry for that.
Michael Becke wrote:
I don't think this is what we want. This patch causes all connections
to be released before execution. The intent was to only release the
connection when an exception occurred and
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
+1
Maybe chunked transfer encoding and URL encoding would fit into this
package as well somehow?
Odi
O'brien, Tim wrote:
Rev 1.1 of Base64 was checked in by Sander Striker about 1 year ago. It was
initially from the HttpClient project.
The codec Base64 class has an open bug which also should
-1
Filtering can be done in most mail clients if the right subject prefixes
are used. A separate list is not necessary.
i.e. use [VOTE][Codec] and not just [VOTE]
for votes interesting for all projects you could use [VOTE][COMMONS] or
[VOTE][ALL] or similar
[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
The problem is that each request is made on a per host basis. Redirects
to different hosts than the original one are currently not supported.
You have to issue a new request to the new host in this situation.
Odi
Schreier, Balz wrote:
hi,
i downloaded the latest release (not alpha, but the
://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
--
To unsubscribe, e-mail: mailto
Not Eric's but Michael Becke's contribution.
ps. Damn whitespace. Sorry for CVS churn.
[EMAIL PROTECTED] wrote:
Contributed by: Eric Johnson
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
jean-frederic clere wrote:
Hi,
I have found a typo in the doc. Find enclosed the patch for it.
Cheers
Jean-frederic
checked in. Thanks for hinting.
Odi
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Sung-Gu wrote:
I think this class should be independent from other classes except for
Java
core classes.
It's for its extensiblity for support of other protocols and user-oriented
ways...
Okay. But this class is in the package httpclient. If it was a generic
class then it should be in a
I agree completely. This is a very clear statement.
Odi
Jeffrey Dever wrote:
Sung-Gu,
Creating a new package org.apache.commons.uri implies creating a new
Jakarta Commons subproject called URI. Are you suggesting that we start
a new project for this?
Instead of saying HttpURL should be useful
I think this is a quite ugly method signature. We already have a
NameValuePair class. I prefer to use an array of thos objects rather
than two unrelated arrays of related values. Furthermore the java doc
does not help the user to understand what should be passed here.
Odi
[EMAIL PROTECTED]
org.apache.commons.httpclient.config;
/**
* Holds the property keys used to configure HttpClient.
* @see Configuration
*
* @author Ortwin Glück
*
* @since 2.0
*/
public interface ConfigKeys {
/** The HTTP version to use. 1.0 means HTTP/1.0, 1.1 means HTTP/1.1 */
public static final
Adrian Sutton wrote:
No authentication required (because a request hasn't yet been made or
because there was no 401 response): return null.
Basic or Digest: return UsernamePasswordCredentials.class
NTLM authentication: return NTCredentials.class
Unsupported authentication scheme: null
Ryan Hoegg wrote:
chunk-extension= *( ; chunk-ext-name [ = chunk-ext-val ] )
chunk-ext-name = token
chunk-ext-val = token | quoted-string
token = 1*any CHAR except CTLs or separators
Since chunk-extension includes only tokens and an = I read this to say
that neither \r or \n is
Could you post the server's response?
Ryan Hoegg wrote:
Although it seems we will be going to BNF as a regex someday, I am
suspicious that this very issue is causing incompatibility with a HTTP
1.1 server I am trying to access. So I may make a stab at parsing this
chunk size thing as I
Jeff Dever wrote:
Hey Odi,
I just made a few minor additions.
Included.
We also have to be careful of the
NumberFormatExceptions that will be thrown by the parseInt() type calls.
Perhaps there should be a ConfigurationException?
Yes I was thinking about this as well. Problem here:
Elwin, Martin wrote:
Ortwin, not sure if I understand why a retry only should be done for 1.1.
Would you mind elaborating on the reasons for that? The current retry logic
is valid for both 1.0 and 1.1, as far as I can tell.
Simply because there is no need for a retry in 1.0. Remember 1.0: The
As suggested by Martin Elwin.
Patch is for .../src/java/
Should we throw an Exception instead of this:
} else {
// this was not CRLF, so now write '\r' + this char
baos.write('\r');
baos.write(b);
state = 0;
}
I mean having \r inside a chunk size field is illegal
for the httpclient package. Instances of
this class
* are immutable.
*
* @author Ortwin Glück
*
* @since 2.0
*/
public class Configuration {
/**
* The default configuration read from file.
*/
public static final Configuration DEFAULT = new Configuration();
public
applied intelligence ag
ortwin glück [www] http://www.nose.ch
hardturmstrasse 171 [email] [EMAIL PROTECTED]
8005 zurich [office] +41-1-277 57 35
switzerland [fax] +41-1-277 57 12
Mark R. Diggory wrote:
1.) Would there be a means to assign my own properties object to the
HttpClient, HttpConnection and HttpMethod objects? So I could control
the settings on a client by client, connection by connection, or
method by method basis?
Yes I think this makes sense. Do we
Your app may want to get the data as an InputStream. Then you can decide
yourself how many bytes you want to read. There might be some issues
with closing the connection before the end of the stream has been reached.
However this is another candidate for a configuration property.
More about
301 - 386 of 386 matches
Mail list logo
