DO NOT REPLY [Bug 22926] New: - Digest auth MD5-sess not supported.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22926. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22926 Digest auth MD5-sess not supported. Summary: Digest auth MD5-sess not supported. Product: Commons Version: unspecified Platform: Other OS/Version: All Status: NEW Severity: Normal Priority: Other Component: HttpClient AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I was attempting to access a device that requires Digest authentication using MD5-sess, which does not seem to be supported. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22926] - Digest auth MD5-sess not supported.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22926. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22926 Digest auth MD5-sess not supported. --- Additional Comments From [EMAIL PROTECTED] 2003-09-04 09:02 --- Created an attachment (id=8058) MD5-sess patch. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HttpGet with Chunked response
You can only be sure by looking at the wirelog. It's possible that there is no reliable way to force Tomcat to deliver chunked output. Odi Dan Tran wrote: It seems this is connector problem, dont you agree? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15435] - New Preferences Architecture
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435 New Preferences Architecture --- Additional Comments From [EMAIL PROTECTED] 2003-09-04 12:28 --- I thought about this quite a bit more last night as I was going to sleep and I have changed my mind, particularly in regard to specific vs. generic configuration. My feeling now is that HttpParams should be a source for generic configuration and that specific configuration should be handled by the specific users of the values. For example HttpParams would have methods like: String getParam(String key) long getLongParam(String key) and default options like: String getParam(String key, String default) long getLongParam(String key, long default) Then classes like HttpVersion or HttpMethodBase would have the specifics like: public static final String PARAM_PROTOCOL_VERSION = http.protocol.version and public static void setHttpVersion(HttpVersion version, HttpParams params) Again, these are just some ideas. I like this separation of things better though. This allows HttpParams to be flexible enough to handle various kinds of configuration, and pushes the specifics to the classes that care about them. What do you think? Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15435] - New Preferences Architecture
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435 New Preferences Architecture --- Additional Comments From [EMAIL PROTECTED] 2003-09-04 13:22 --- Some quick thoughts from here, having scanned the proposed patch only very briefly: * I like the idea of keeping parameters generic. I use the Slide WebDAV extensions, and likely there will be options that make sense to specify for that in the future (default encoding of XML requests, for example). Clients may also have preferences that they associate with HttpClient, but are not necessarily used by HttpClient. By keeping the options generic, extensions like WebDAV, and other client wrappers can use the same mechanism for setting their preferences. If you make the settings functions specific, it will be harder over time for the library to accommodate new options, and clients will not be able to extend it as easily. * The discovery process standard could use the approach outlined here: http://java.sun.com/j2se/1.4.2/docs/api/javax/xml/parsers/SAXParserFactory.html#newInstance() which is as close to a standard as Java has for this kind of thing. * Ortwin has an excellent point, namely that the discovery process should kick in only if the caller doesn't provide default information. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15435] - New Preferences Architecture
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435 New Preferences Architecture --- Additional Comments From [EMAIL PROTECTED] 2003-09-04 14:22 --- Folks, It's my first day at work after two weeks of holidays, so things are a bit hectic right now. I'll try to respond to every comment made but that may take a while and a few postings # 2 - indirection http.dateFormats=format1, format2 format1=EEE, dd-MMM- HH:mm:ss z format2=EEE dd-MMM- HH-mm-ss z That's the way Sun does it, and it may well be the way most users would expect it to work (me for one) - Is there a need for both specific configuration params like getConnectionManagerTimeout() and generic ones like getParameter (String)? Not really. I also agree that ideally two methods should not be mixed up. I sense that the majority of respondent favor the generic approach over specific, like I do. I just felt that having to parse some frequently values such as protocol version might be too much of a performance hit. I thought an exception could be made for the most frequently used parameters (maybe just protocol version). However, if we all agree that performance degradation will be offset by greater flexibility, I do not mind taking purely generic approach - I think HttpParams.load() should use a PropertyResourceBundle to load/parse the configuration. It avoids implementing the nasty details and provides support for splitting lines with \, among other things. Agreed. - I think we probably want a HttpMethodBase.setParams() or something of the sort. Can do. Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15435] - New Preferences Architecture
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435 New Preferences Architecture --- Additional Comments From [EMAIL PROTECTED] 2003-09-04 14:26 --- I don't like the generic approach so much. It involves defining property names which introduce typos and requires converting data representations. If you know you need a boolean to indicate whether redirects should be chased or not (just to give an example), give it a setter and a getter and let the compiler check for typos. To me, a generic mechanism is something for things we haven't thought about, or things we couldn't know about in Eric's case. Useful, but rather a fallback than a preferred choice. Unfortunately, I won't find the time to look at the code in the near future. But is there a way to have base class that provides a generic mechanism and to use adapter classes for the individual components? Something like: HttpParams: generic parameters and conversion methods from and to strings HttpClientParams: specific getters and setters for the client's properties, kept in attributes. Constructor and/or readFrom(HttpParams) to initialize the attributes, and saveTo(HttpParams) to write them back. HttpMethodParams: like HttpClientParams, just for the HttpMethodBase params HttpGetMethodParams: derived from HttpMethodParams, adding some GET-specific attributes. ...and so on for every component that defines parameters I know this may create a lot of new classes, but I always was a friend of lots of (simple) classes :-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Release date for httpclient 2.0 final?
Vincent, Truth to be told, I see late September as not impossible but highly unlikely 2.0 final release date. We have had way too many bug reports recently (nothing really critical but just too many) to be in a position to rush the final release. There will be at least RC2 and RC3. Besides, there is still one major task to be finished: javadoc cleanup. It is a painfully slow and unpleasant undertaking. It will take a few rainy weekends. I fear there may be no final release until late October - mid November. Yet, I will be glad to be proven wrong. When is your book to go to print? Kind regards, Oleg On Fri, 2003-08-22 at 20:29, Vincent Massol wrote: -Original Message- From: Ortwin Glück [mailto:[EMAIL PROTECTED] Sent: 22 August 2003 17:56 To: Commons HttpClient Project Subject: Re: Release date for httpclient 2.0 final? Vincent, As you know we have a RC1 currently. There is basically only documentation and integration work going on. Oleg Kalnichevski, one of the leading developers, is on vacation at the moment. So we will probably not make a release until he returns (in two weeks time AFAIK). I am sorry that I can not give you an exact date. Personally I expect 2.0 by end of September. Ok. Thats some good piece of information. Thanks -Vincent Regards Odi Vincent Massol wrote: Hi, I'm finishing a book on unit testing java applications (JUnit in Action). I'm using Cactus in some chapters, which in turn uses Commons-httpclient. The version of httpclient I'm using in the book is currently 2.0-rc1. However, in anticipation of a future final release of 2.0, I've taken the risk to refer to the 2.0 version in the different chapters of the book. I'd like to know if you have a target date for the 2.0 release so that I can check if it will happen before the publication of my book or after... :-) Thanks -Vincent - To unsubscribe, e-mail: commons-httpclient-dev- [EMAIL PROTECTED] For additional commands, e-mail: commons-httpclient-dev- [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22073] - Javadocs clean-up
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22073. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22073 Javadocs clean-up --- Additional Comments From [EMAIL PROTECTED] 2003-09-04 20:54 --- The patch looks good to me. Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: regression in cookie handling from 2.0 alpha3 to 2.0 rc 1 ?
Eric, You are not the first one to complain about the problem. I think there's a fairly easy way of solving it: all we have to do is to ensure that only only automatically generated 'cookie' headers can ever be overwritten. Feel free to file a bug report. Oleg On Tue, 2003-08-26 at 03:10, Eric Bloch wrote: Hi Adrian, Thanks for the quick response! My problem is that I don't have a 'Cookie' object. I only have the text string for the name of the cookie and its value and I couldn't see any easy way for me to construct up a Cookie object from that... or any exposed http cookie header (not set-cookie header) parsing that would make it easy for me to construct up the Cookie object from my text (Im essentially reading a 'cookie' header myself and proxying the cookie over to another http server via the httpclient library). Parsing the cookie could actually be wasted cycles, too, because I don't maintain any state between requests; I create and destroy an HttpClient for each request (GetMethod) I execute. I'm happy with my current workaround, but it means I'll have to make sure the implementation bits don't change too much between revs, as you guys continue on. Again, thanks for your time and nice work! -Eric Adrian Sutton wrote: Hi Eric, If I manually set a cookie header on a request (for example, if I'm proxying a request myself), HttpMethodBase will always clobber it during addCookieRequestHeader(). I would think that it should merge in any client state cookies to the header I add, rather than clobbering mine. You should add cookies using the HttpState.addCookie method rather than adding it directly as a header, then it won't be clobbered and will be correctly merged into any other cookies being sent. We don't consider the current behaviour a bug, though if enough people requested it I imagine it would be possible to change. Regards, Adrian Sutton. -- Intencha tomorrow's technology today Ph: 38478913 0422236329 Suite 8/29 Oatland Crescent Holland Park West 4121 Australia QLD www.intencha.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: A bug?
Roland, Mike and all. Not only it appears to be a reasonable order of things, it also seems to correspond to Sun's official recommendations ... out.close(); in.close(); ... echoSocket.close(); ... These statements close the readers and writers connected to the socket and to the standard input stream, and close the socket connection to the server. StrongThe order here is important/Strong. You should close any streams connected to a socket before you close the socket itself. ... Java tutorial http://java.sun.com/docs/books/tutorial/networking/sockets/readingWriting.html On Tue, 2003-09-02 at 07:19, Roland Weber wrote: Hello Mike, I think closing the output stream first is the right thing to do. Someone might want to send a shutdown notification to the server before stopping to receive, e.g. for SSL connections. regards, Roland Michael Becke [EMAIL PROTECTED] 01.09.2003 21:16 Please respond to Commons HttpClient Project To: Commons HttpClient Project [EMAIL PROTECTED] cc: Subject:Re: A bug? Yes, this is a good point. We might as well be as thorough as possible. The only real change that might make sense in reversing the order in which streams are closed. Is sounds like Yue would like to have the output stream closed before the input. Anyone have objections to this? Mike On Monday, September 1, 2003, at 07:46 AM, Roland Weber wrote: Michael Becke wrote: Any thoughts on why we close the streams and then the socket? Someone might have implemented sockets with buffered streams. Closing only the socket directly would not dispose of the buffers. Given the SocketFactory stuff, that possibility shouldn't be ruled out. just my thoughts :-) Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VFS|HttpClient] Re: [VFS] Crashes in getContent()
Folks, what was the outcome of this discussion? From my perspective, it fizzled and died here. I logged a bug report on HttpClient (on one crash I received) but I don't believe any action has occurred. The Krysalis stack of projects still fail nightly on Gump with VFS/HttpClient. Please see: http://cvs.apache.org/builds/gump/latest/krysalis-version.html http://cvs.apache.org/builds/gump/latest/krysalis-centipede-site.html That said, these here look like VFS crashes, however I believe they are due to an earlier HttpClient crash. The stack I logged went into HttpClient and crashed there, something to do with processing a simple redirect. BTW: The lack of progress on this has finally pushed me to begin a re-write of Krysalis Ruper to make VFS HttpClient optional. The re-write is a good thing for itself, but the inability to rely upon this foundation is disappointing. regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
