Re: Post Method

In theory I agree, but I see a lot of uses of the O'Reilly multipart stuff, which expects "multipart/form-data" (see: http://www.servlets.com/cos/javadoc/com/oreilly/servlet/multipart/ MultipartParser.html) Yes, please take a look at MultipartPostMethod. I had a specific problem with the and x-

Re: SSL & Phaos

I don't know much about Phaos but it looks like they extend the Java Socket class. If this is the case it should be pretty easy. There is not any released documentation talking about how to use a custom SSL implementation but there is something pre-release if you would like to take a look. P

Re: Post Method

In theory I agree, but I see a lot of uses of the O'Reilly multipart stuff, which expects "multipart/form-data" (see: http://www.servlets.com/cos/javadoc/com/oreilly/servlet/multipart/MultipartParser.html) I had a specific problem with the and x-www-form-urlencoded last week, which is why I'm usin

Re: Post Method

There seems to be quite a bit of discussion regarding this question but not too much that seems ultimately definitive. This one seems to be the best: http://groups.google.com/groups?oi=djq&selm=an_537840002 Essentially the author says that form encoding and URI encoding are two unrelated thin

Re: Post Method

Yes, this can be accomplished with the MultipartPostMethod. But as you mentioned I think this is meant for posting larger, perhaps binary, content in combination with standard text parameters. Mike On Tuesday, June 10, 2003, at 01:46 PM, Laura Werner wrote: Kalnichevski, Oleg wrote: must the

DO NOT REPLY [Bug 20665] - URI path resolution problems.

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 20665] New: - URI path resolution problems.

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 20569] - error handling duplicate connection headers

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

SSL & Phaos

I guess what I am looking for is SSL using Phaos implementation. What I really want to be able to do is, configure the SSL related parameters on a per connection basis. I will appreciate if anyone can help me on this. Thanks. >>> [EMAIL PROTECTED] 6/10/2003 2:28:41 PM >>> Does anyone has sample c

Re: NTLM

Hi Adrian, Thanks for pointing. The credentials were wrong. Fixed the credentials and that fixed the problem. Thanks. >>> [EMAIL PROTECTED] 6/10/2003 5:46:24 PM >>> Your username, password and/or domain are incorrect. The wire log shows everything technically going smoothly but the server stil

Re: NTLM

Your username, password and/or domain are incorrect. The wire log shows everything technically going smoothly but the server still rejects the credentials. If you are absolutely certain that your credentials are correct, please send through the exact details of the webserver your using alon

SSL

Does anyone has sample code to do GET/POST on a https url? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

Re: org.apache.commons.httpclient.util.DateParser

> In general I think it would be nice for HttpClient to have more tools > for handling headers. One option would be to add a bunch of methods to > HttpMethod, but I think this would add too much clutter. Perhaps we > should have a "HeaderUtil" class with convenience methods for parsing,

Re: URI specification

Mike, I think you should give it another shot and file a proposal for URI classes to be moved into Commons sandbox project of its own. I do not think of deprecation of URI classes as a big issue. We may continue supporting our own copy of URI classes while commons-uri is the sandbox. I really think

DO NOT REPLY [Bug 20569] - error handling duplicate connection headers

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

RE: preemptive

As I said before, currently only Basic authentication can be used preemptively. As far Digest scheme goes, theoretically it may be possible to preemptively authenticate against a Digest protected resource for which 'nonce', 'nonce count' and 'opaque' values are known. There's no guarantee that a ta

NTLM

Tried to Authenticate using NTLM. Attached is JCTest.java sample code and debug trace in debug.txt. It comes back finally as "Access Denied". Does anyone has a clue? Thanks. [DEBUG] HttpConnection - -Creating connection for localhost using protocol http:80 [DEBUG] HttpConnection - -HttpConnection.

RE: preemptive

I removed the Log4J from my classpath and could produce debug info. Attached is the trace I got when authenticating for Diegest on Tomcat. As per what I understand, Tomcat supports connection reuse. What I would like to see is that HttpClient store the Authorization header for a URL and resend it w

RE: preemptive

Zulfi Both Digest & NTLM authentication schemes are connection oriented. Every time a new connection is open to a Digest & NTLM protected resource, the user has to be re-authenticated. Per default HttpClient does its best to keep connections alive, provided that the server supports connection

Re: preemptive

For logging to work when just setting the system properties, log4j cannot be on the classpath. Log4j will override any settings specified via system property. If you have log4j on the classpath you will have to configure it via standard log4j mechanisms. Mike Zulfi Umrani wrote: What do you

RE: preemptive

What do you mean by "eliminating the authentication overhead"? Does this mean keeping the already Authenticated header and adding it next time the URL is being invoked? I am using Apache Tomcat Server to host a couple of protected URLs. One more Basic and other for Digest. I believe it does the nec

Re: Post Method

Kalnichevski, Oleg wrote: must the body of a post request be encoded as a URL Query? Yes, it must, when the post body content is specified as a set of name/value pairs. I think you're also allowed to use the multipart/form-data MIME type rather than application/x-url-encoded (or whatever i

RE: preemptive

Zulfi, Only Basic authentication scheme can be used preemptively. If you want to eliminate the authentication overhead associated with Digest or NTLM schemes you have to ensure that the HTTP server keeps connections alive when possible. Please get logging to work. That should not be too difficul

RE: preemptive

By setting realm as null, the pre-emptive authentication worked! But, it sends a Basic Authorization header even if the URL is protected by Digest! For Digest it is still making 2 trips in order to authenticate. Which is fine for the first request, but it repeats the same thing for the second reque

Re: Post Method

Michael Becke wrote: I think there may be a bug here as well. According to the spec, space characters should be represented as '+' but URIUtil is encoding them as '%20'. I think the resevered character set is perhaps also incorrect. According to rfc 1738 ";", "/", "?", ":", "@", "=" and "&" ar

Re: preemptive

Hi Mike, I set the properties as specified by the link you sent. It did not produce any log on the stdout! If you have a piece of the code that does that, please send that to me. Thanks. >>> [EMAIL PROTECTED] 6/9/2003 10:48:36 PM >>> Zulfi, Please send a wire and trace log. It is difficult to r

Re: Post Method

I think there may be a bug here as well. According to the spec, space characters should be represented as '+' but URIUtil is encoding them as '%20'. I think the resevered character set is perhaps also incorrect. According to rfc 1738 ";", "/", "?", ":", "@", "=" and "&" are the reserved chars

RE: Post Method

> must the body of a post request be encoded as a URL Query? Yes, it must, when the post body content is specified as a set of name/value pairs. For more details you may refer to http://www.w3.org/MarkUp/html-spec/html-spec_8.html#SEC8.2.1 One can still provide a raw post body and a custom con

Re: Post Method

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. ---

DO NOT REPLY [Bug 20646] - Via NTLM proxy to SSL Apache/BasicAuth. - worked in may 22nd, but broken in beta1

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 20646] - Via NTLM proxy to SSL Apache/BasicAuth. - worked in may 22nd, but broken in beta1

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

Post Method

Strange Behavior in Post Methods. generateRequestBody() ... queryName = URIUtil.encodeWithinQuery(parameter.getName(), charset); ... queryValue = URIUtil.encodeWithinQuery(parameter.getValue(), charset); ... must the body of a post request be encoded as a URL Query? This is because some

DO NOT REPLY [Bug 20646] - Via NTLM proxy to SSL Apache/BasicAuth. - worked in may 22nd, but broken in beta1

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 20646] - Via NTLM proxy to SSL Apache/BasicAuth. - worked in may 22nd, but broken in beta1

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 20646] - Via NTLM proxy to SSL Apache/BasicAuth. - worked in may 22nd, but broken in beta1

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 20646] New: - Via NTLM proxy to SSL Apache/BasicAuth. - worked in may 22nd, but broken in beta1

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

Re: org.apache.commons.httpclient.util.DateParser

Christopher, Please note my comments below. The "private static final String[] DATE_PATTERNS" might be more efficiently declared as an array of DateFormat instances (never publicly accessible, as that could be tampered with using the "apply" method for example), as that avoids repeat parsin

Fwd: org.apache.commons.httpclient.util.DateParser

Please note the following questions/comments regarding DateParser. Mike Begin forwarded message: From: "Christopher Brown" <[EMAIL PROTECTED]> Date: Tue Jun 10, 2003 5:34:51 AM US/Eastern To: "Michael Becke" <[EMAIL PROTECTED]> Subject: org.apache.commons.httpclient.util.DateParser Hi Michael,

Re: File Upload Progress Meter

Yes, this is how I have used it in the past. I wrapped the InputStream to be returned from PartSource.createInputStream() in a class that counted the number of bytes read and periodically fired an event. Mike On Tuesday, June 10, 2003, at 04:13 AM, Ortwin Glück wrote: I think it's easier to c

MultiparPostMethod

Hi Folks! Is there any bug related with MultipartPostMethod?. The servlet that receives my file throws an exception reading the part. 2003-06-05 12:13:22,890 [jcp-11] ERROR excepcion - 1054811602890|java.lang.String.incluirAnexoBD|java.io.IOException|Fin de arte inexperado java.

Re: File Upload Progress Meter

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 l

RE: File Upload Progress Meter

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 liking. We, HttpClient developers, may consider adding events in 2.1 or 3.0 release as a standard feature. For the time being, a HttpClient fork appears your only o

RE: preemptive

Zulfi, Try setting both realm & host to null. That should do the trick HttpClient hc = new HttpClient(); HttpState state = hc.getState(); state.setAuthenticationPreemptive(true); // Set default credentials (realm & host are null) state.setCredentials(null, nu

File Upload Progress Meter

Hi. I'm using the MultipartPostMethod to upload images to a server. I want to add a progress meter that shows what percentage has been uploaded along with some other statistics (time remaining, speed, etc). I spent some time looking around and it looks like the code that I need to add to (the