DO NOT REPLY [Bug 20240] - Cookies with null path attribute are rejected in the compatibility mode
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=20240. 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=20240 Cookies with null path attribute are rejected in the compatibility mode --- Additional Comments From [EMAIL PROTECTED] 2003-07-03 09:31 --- Hi, First thanks for your reactivity and your contribution to free software. I did download v2.0-beta2 but you're right, patch has been applied, I mistaked files sorry. But the problem remains. I think I understand what happened, I did download beta-1, applied the patch myslef by hand and I made a mistake that made it work, but the patch correctly applied doesn't work. I think that only the patch on CookieSpecBase.java should be applied, the patch on RFC2109Spec.java stills throws an exception line 119. I mofified it today on a snapshot and it works for me. Simply remove patch on RFC21109Spec.java, so remove lines from 116 to 127 and line 128 replace else if by if. Sorry for the mistake. Mickael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20240] - Cookies with null path attribute are rejected in the compatibility mode
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=20240. 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=20240 Cookies with null path attribute are rejected in the compatibility mode --- Additional Comments From [EMAIL PROTECTED] 2003-07-03 09:54 --- Mickael, The cookie in question still violates RFC 2109 and therefore should be rejected in RFC2109 mode (default). The cookie _should_ be acceptable in the compatibility mode, though. The patch was intended to fix compatibility cookie mode only. Sorry for not having been clear enough. Please give the compatibility cookie policy a try. Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Is HttpClient supported by non-Sun VMs?
Hi, I want to use HttpClient inside an applet that will run in both Microsoft VM (Internet Explorer) and MRJ (Macintosh browsers). Are those supported Virtual Machines? Thanks! Robert
Re: Why non-buffered InputStream in HttpClient / HttpParser?
I'm wondering: *if* the HttpParser.readLine method (and subsequent calls to .readRawLine) is called much more frequently than other methods/classes that tap into InputStream, perhaps a start would be to modify the code in .readRawLine to use a BufferedReader+ BufferedInputStream. That might yield some significant gains for small effort. I'm just speculating here. Yes, this is where HttpClient does most (if not all) of its reading. The problem with adding buffering at this level is that content data will also be buffered. Once buffered this data would be lost to code not using the same instance of the BufferedInputStream. If we want buffering I think we will have to implement it at the HttpConnection level or just leave it to the user for content data. Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Is HttpClient supported by non-Sun VMs?
Oleg, That's what I was affraid of. The only reason I wanted to use it in my applet was to solve memory issues for large file uploads (java.net.URLConnection allways buffers the output before sending and for large files I got out of memory error message). The applet is part of a product that must support all Windows and Macintosh browsers. Having that known, I cannot use HttpClient and have to try another solution to handle my issue. Thank you. Robert -Original Message- From: Kalnichevski, Oleg [mailto:[EMAIL PROTECTED] Sent: July 3, 2003 10:42 AM To: Commons HttpClient Project Subject: RE: Is HttpClient supported by non-Sun VMs? Robert, If my memory does not fail me, IE is shipped with Microsoft JVM 1.1.4. HttpClient requires a Java 2 compatible (1.2.x and above) JVM. I am afraid your only option is to deploy Sun's Java plug-in for IE if you want to be using HttpClient in an applet. As to Mac OS 9.x, to my best knowledge, Java 2 is not even officially supported by Apple on that platform. The highest JVM version supported on MacOS 9.x is 1.1.8. Oleg -Original Message- From: Robert Csiki [mailto:[EMAIL PROTECTED] Sent: Thu 7/3/2003 16:06 To: '[EMAIL PROTECTED]' Cc: Subject:Is HttpClient supported by non-Sun VMs? Hi, I want to use HttpClient inside an applet that will run in both Microsoft VM (Internet Explorer) and MRJ (Macintosh browsers). Are those supported Virtual Machines? Thanks! Robert
Re: Is HttpClient supported by non-Sun VMs?
Robert, They way I solved this for one project was to do a custom uploader to my own servlet. You can get much better performance streaming your own binary data to a servlet you control. You can even deflate the data first. David Robert Csiki wrote: Oleg, That's what I was affraid of. The only reason I wanted to use it in my applet was to solve memory issues for large file uploads (java.net.URLConnection allways buffers the output before sending and for large files I got out of memory error message). The applet is part of a product that must support all Windows and Macintosh browsers. Having that known, I cannot use HttpClient and have to try another solution to handle my issue. Thank you. Robert -Original Message- From: Kalnichevski, Oleg [mailto:[EMAIL PROTECTED] Sent: July 3, 2003 10:42 AM To: Commons HttpClient Project Subject: RE: Is HttpClient supported by non-Sun VMs? Robert, If my memory does not fail me, IE is shipped with Microsoft JVM 1.1.4. HttpClient requires a Java 2 compatible (1.2.x and above) JVM. I am afraid your only option is to deploy Sun's Java plug-in for IE if you want to be using HttpClient in an applet. As to Mac OS 9.x, to my best knowledge, Java 2 is not even officially supported by Apple on that platform. The highest JVM version supported on MacOS 9.x is 1.1.8. Oleg -Original Message- From: Robert Csiki [mailto:[EMAIL PROTECTED] Sent: Thu 7/3/2003 16:06 To: '[EMAIL PROTECTED]' Cc: Subject:Is HttpClient supported by non-Sun VMs? Hi, I want to use HttpClient inside an applet that will run in both Microsoft VM (Internet Explorer) and MRJ (Macintosh browsers). Are those supported Virtual Machines? Thanks! Robert
RE: Is HttpClient supported by non-Sun VMs?
Robert, Welcome to the club. I use HttpClient for a similar purpose: exchanging XML formatted files between a client and a server, (or as I like referring to it: poor man's SOAP). And [sigh] I do have to support all those two and a half users who insist on using MacOS 9.x with no Java 2 compatible JVM. If you do not need a full blown HTTP protocol support, you might be much better off just writing to a raw socket. I am not that lucky. I'll have to fork HttpClient at some point and port it to Java 1.1.8. Oleg -Original Message- From: Robert Csiki [mailto:[EMAIL PROTECTED] Sent: Thu 7/3/2003 16:51 To: 'Commons HttpClient Project' Cc: Subject:RE: Is HttpClient supported by non-Sun VMs? Oleg, That's what I was affraid of. The only reason I wanted to use it in my applet was to solve memory issues for large file uploads (java.net.URLConnection allways buffers the output before sending and for large files I got out of memory error message). The applet is part of a product that must support all Windows and Macintosh browsers. Having that known, I cannot use HttpClient and have to try another solution to handle my issue. Thank you. Robert -Original Message- From: Kalnichevski, Oleg [mailto:[EMAIL PROTECTED] Sent: July 3, 2003 10:42 AM To: Commons HttpClient Project Subject: RE: Is HttpClient supported by non-Sun VMs? Robert, If my memory does not fail me, IE is shipped with Microsoft JVM 1.1.4. HttpClient requires a Java 2 compatible (1.2.x and above) JVM. I am afraid your only option is to deploy Sun's Java plug-in for IE if you want to be using HttpClient in an applet. As to Mac OS 9.x, to my best knowledge, Java 2 is not even officially supported by Apple on that platform. The highest JVM version supported on MacOS 9.x is 1.1.8. Oleg -Original Message- From: Robert Csiki [mailto:[EMAIL PROTECTED] Sent: Thu 7/3/2003 16:06 To: '[EMAIL PROTECTED]' Cc: Subject:Is HttpClient supported by non-Sun VMs? Hi, I want to use HttpClient inside an applet that will run in both Microsoft VM (Internet Explorer) and MRJ (Macintosh browsers). Are those supported Virtual Machines? Thanks! Robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why non-buffered InputStream in HttpClient / HttpParser?
On Thursday, July 3, 2003, at 10:44 AM, Michael Becke wrote: I'm wondering: *if* the HttpParser.readLine method (and subsequent calls to .readRawLine) is called much more frequently than other methods/classes that tap into InputStream, perhaps a start would be to modify the code in .readRawLine to use a BufferedReader+ BufferedInputStream. That might yield some significant gains for small effort. I'm just speculating here. Yes, this is where HttpClient does most (if not all) of its reading. The problem with adding buffering at this level is that content data will also be buffered. Once buffered this data would be lost to code not using the same instance of the BufferedInputStream. If we want buffering I think we will have to implement it at the HttpConnection level or just leave it to the user for content data. Thanks for the explanation. I'm hoping for a good buffering solution by 2.1 or 3. Tony - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
How to interrupt connexion ?
Hello, I am doing a small application which send file via MultiPartPost... class to a web server. This application launches internaly several threads, each one establishing a connection with different servers. Everything is working fine but I am not able to stop a transfert that is waiting for the connection timeout to stop : timeout is very long - several hours - and releaseConnection(), Thread.interrupt() don't work. The thread doesn't stop. Can you help me ? Thanks Damien Lecan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is HttpClient supported by non-Sun VMs?
I was just looking at how much work is required to make HttpClient work in a 1.1 JVM. Suprisingly it would not be that hard. Mostly it would just require the 1.1 collections jar and some package import rewriting. There are a few things like GCed connection reclaiming in MultiThreadedHttpConnectionManager and the use of Socket.sendBufferSize() that would need to be removed but that's about it. Is there enough interest in 1.1 support for a semi-supported version? Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to interrupt connexion ?
Do you want to interrupt the sending of data or the creation of a connection? Mike [EMAIL PROTECTED] wrote: Hello, I am doing a small application which send file via MultiPartPost... class to a web server. This application launches internaly several threads, each one establishing a connection with different servers. Everything is working fine but I am not able to stop a transfert that is waiting for the connection timeout to stop : timeout is very long - several hours - and releaseConnection(), Thread.interrupt() don't work. The thread doesn't stop. Can you help me ? Thanks Damien Lecan - 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]
Occassional long download times
I'm experiencing something weird and I just want to see if anyone else has experienced it, and if it may be something I'm doing. Basically my application is monitoring 700+ websites every 5 minutes and timing the time it takes to connect and download. The main goal is to verify the site is working, so I don't need exact precision on the times. Here's some of my code to time the download: method = new GetMethod(uri.toString()); method.setFollowRedirects(true); method.setHttp11(false); DefaultMethodRetryHandler retry = new DefaultMethodRetryHandler(); retry.setRequestSentRetryEnabled(true); retry.setRetryCount(3); method.setMethodRetryHandler(retry); start = System.currentTimeMillis(); method.execute(state, connection); msi.setDuration(System.currentTimeMillis() - start); What I see is that normally I get download times 150ms and then occassionally (4-5 times a day) I see a download time of 3000ms. It happens to the majority of the websites, so I do not believe it's a particular site. So it must be either my application, or the network. My application uses a thread pool and always has multiple threads running (typically 8 at a time on a 4 CPU machine that's also running tomcat and Postgres), and I've seen that at exactly the same time a website has a 3000ms download time several others have normal 150ms times. So this seems to rule out the network. I set my threads to be all MAX_PRIORITY to minimize the interruptions. Are there any other explanations? Any ideas what I can do about it? My current thought is to put in some code to say if the download time is more than 10x the previous time then repeat the download to make sure. This way our customers wouldn't see the huge spike in the numbers, but at the same time if that spike really should be there I don't want to cover it up. Thanks, Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Transporting large files with HttpClient
I've found the request body's content length (set via PostMethod.setRequestContentLength) is stored by an *int* What happens if I want to upload a large file, lets say a 10GB file? Thanks. Robert
Re: Transporting large files with HttpClient
You better have a LOT of time on your hands! (and hope the http connection stays up long enough) heh heh... Robert Csiki wrote: I've found the request body's content length (set via PostMethod.setRequestContentLength) is stored by an *int* What happens if I want to upload a large file, lets say a 10GB file? Thanks. Robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is HttpClient supported by non-Sun VMs?
Yes NTLM and SSL would probably be lost. I agree. I think 1.1 is old enough that it should be forgotten. Having said that, doing some minor refactoring work to make HttpClient work in 1.1 is certainly much better then reinventing the wheel. I guess my intent is to encourage people to make their own 1.1 port of HttpClient. I was able to get the unit tests (local and no host) up and running in eclipse with 1.1 in about 15 minutes. This is not something that I would like to maintain alongside the standard HttpClient, but it certainly can be done. Mike Oleg Kalnichevski wrote: NTLM SSL as standard features would also have to go (there are some Java 1.1 compatible JCE JSSE implementations but I do not know of any available under open-source licence) In general the use of Java 1.1 should be strongly discouraged in my opinion. The users of legacy platforms like Mac OS 10 and IE should feel the pressure to upgrade (side-grade in case of IE ;-)) Oleg On Thu, 2003-07-03 at 19:34, Michael Becke wrote: I was just looking at how much work is required to make HttpClient work in a 1.1 JVM. Suprisingly it would not be that hard. Mostly it would just require the 1.1 collections jar and some package import rewriting. There are a few things like GCed connection reclaiming in MultiThreadedHttpConnectionManager and the use of Socket.sendBufferSize() that would need to be removed but that's about it. Is there enough interest in 1.1 support for a semi-supported version? Mike - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Transporting large files with HttpClient
There are two ways I can see to get around this. 1) Use chunked encoding via method.setContentLength(EntityEnclosingMethod.CONTENT_LENGTH_CHUNKED). 2) Use the MultipartPostMethod. This method uses a long for the content length of each part. We should probably change the EntityEnclosingMethod content length field to a long in a future release. Would you like to put in a Bugzilla enhancement request for this? Mike Robert Csiki wrote: I've found the request body's content length (set via PostMethod.setRequestContentLength) is stored by an *int* What happens if I want to upload a large file, lets say a 10GB file? Thanks. Robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21323] New: - Support for handling large files should be added
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=21323. 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=21323 Support for handling large files should be added Summary: Support for handling large files should be added Product: Commons Version: 2.0 Beta 2 Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: HttpClient AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] You should probably change the EntityEnclosingMethod content length field to a long in a future release. Currently it's an int. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21323] - Support for handling large files should be added
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=21323. 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=21323 Support for handling large files should be added --- Additional Comments From [EMAIL PROTECTED] 2003-07-03 18:46 --- HttpMethod#getContentLength method should also be changed accordingly. Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to interrupt connexion ?
Oleg Kalnichevski wrote: Sadly enough, there's (there will be) no reliable way to interrupt a request in the release 2.0. It is an unfortunate oversight on our part. This feature is planned for the 2.1 release: This is a hard problem, because almost all of the calls in the old java.io library are non-interruptible. There's no good way to, for example, have a background thread whose job is to interrupt requests that have taken too long. In our current code, we fake interruptible threads by using (pooled) background threads to execute the requests. When the timeout interval expires, we give up on waiting for the background thread to finish the fetch and just throw a timeout exception. But I haven't found a way to make the background thread actually stop the fetch, so it just sits there until the socket timeout (if any) triggers an IOException. At that point we can recycle the thread back into the pool. This is very error-prone, though; I'm currently trying to track down a nasty synchronization bug in the threading. To make this feature work, we'd probably have to do something like this: - Add a timeout property to HttpMethod or HttpMethodBase - Just before executing a method, set an internal endTime property - Every time we're about to do a socket operation, e.g. in AutoCloseInputStream.read(), compare the current time and endTime. If we're past endTime, though an exception. If not, adjust the socket timeout so that the read operation can't go past endTime. - Do similar things while waiting on the connection pool, opening sockets, etc. Yuck. I keep thinking there *must* be a simpler way, but I haven't found it yet. -- Laura - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to interrupt connexion ?
This may be an ignorant question, but here it goes: Couldn't you have an interrupt method that calls close() on the underlying streams, then calls close() on the socket itself? If I recall correctly, calling close() on a socket causes any thread that is blocked on that socket to throw a SocketException. But it should work if you shut down the associated streams first, right? --Nathan McMinn - Original Message - From: Laura Werner [EMAIL PROTECTED] To: Commons HttpClient Project [EMAIL PROTECTED] Sent: Thursday, July 03, 2003 3:12 PM Subject: Re: How to interrupt connexion ? Oleg Kalnichevski wrote: Sadly enough, there's (there will be) no reliable way to interrupt a request in the release 2.0. It is an unfortunate oversight on our part. This feature is planned for the 2.1 release: This is a hard problem, because almost all of the calls in the old java.io library are non-interruptible. There's no good way to, for example, have a background thread whose job is to interrupt requests that have taken too long. In our current code, we fake interruptible threads by using (pooled) background threads to execute the requests. When the timeout interval expires, we give up on waiting for the background thread to finish the fetch and just throw a timeout exception. But I haven't found a way to make the background thread actually stop the fetch, so it just sits there until the socket timeout (if any) triggers an IOException. At that point we can recycle the thread back into the pool. This is very error-prone, though; I'm currently trying to track down a nasty synchronization bug in the threading. To make this feature work, we'd probably have to do something like this: - Add a timeout property to HttpMethod or HttpMethodBase - Just before executing a method, set an internal endTime property - Every time we're about to do a socket operation, e.g. in AutoCloseInputStream.read(), compare the current time and endTime. If we're past endTime, though an exception. If not, adjust the socket timeout so that the read operation can't go past endTime. - Do similar things while waiting on the connection pool, opening sockets, etc. Yuck. I keep thinking there *must* be a simpler way, but I haven't found it yet. -- Laura - 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: How to interrupt connexion ?
Laura, In my infamous 1.1.8 fork I implemented an ugly, but very effective solution. I have two threads: a communication thread and an observer thread. The observer thread simply closes the damn socket when the user hits the cancel button. Whuch. The communication thread immediately throws an IOException and happily terminates. There's almost 100% certainty that the server will not receive the request in its entirety. I also attempt to cleanly shutdown input/output streams ob the socket when running on JDK 1.3 and higher (where such feature is available), prior to forcefully closing the socket. It works just fine for me. Cheers Oleg On Thu, 2003-07-03 at 22:12, Laura Werner wrote: Oleg Kalnichevski wrote: Sadly enough, there's (there will be) no reliable way to interrupt a request in the release 2.0. It is an unfortunate oversight on our part. This feature is planned for the 2.1 release: This is a hard problem, because almost all of the calls in the old java.io library are non-interruptible. There's no good way to, for example, have a background thread whose job is to interrupt requests that have taken too long. In our current code, we fake interruptible threads by using (pooled) background threads to execute the requests. When the timeout interval expires, we give up on waiting for the background thread to finish the fetch and just throw a timeout exception. But I haven't found a way to make the background thread actually stop the fetch, so it just sits there until the socket timeout (if any) triggers an IOException. At that point we can recycle the thread back into the pool. This is very error-prone, though; I'm currently trying to track down a nasty synchronization bug in the threading. To make this feature work, we'd probably have to do something like this: - Add a timeout property to HttpMethod or HttpMethodBase - Just before executing a method, set an internal endTime property - Every time we're about to do a socket operation, e.g. in AutoCloseInputStream.read(), compare the current time and endTime. If we're past endTime, though an exception. If not, adjust the socket timeout so that the read operation can't go past endTime. - Do similar things while waiting on the connection pool, opening sockets, etc. Yuck. I keep thinking there *must* be a simpler way, but I haven't found it yet. -- Laura - 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: How to interrupt connexion ?
Oleg Kalnichevski wrote: The observer thread simply closes the damn socket when the user hits the cancel button. Whuch. The communication thread immediately throws an IOException and happily terminates. Good idea! We could implement this in HttpClient by having one master observer thread whose job was to close a connection's socket whenever a Method using that connection has timed out. I also attempt to cleanly shutdown input/output streams ob the socket With HttpConnection.closeSocketAndStreams or its equivalent? -- Laura - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21329] New: - Add InputStream buffering.
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=21329. 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=21329 Add InputStream buffering. Summary: Add InputStream buffering. Product: Commons Version: 2.0 Beta 2 Platform: Other OS/Version: Other Status: NEW Severity: Enhancement Priority: Other Component: HttpClient AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Currently HttpClient does not buffer the InputStream received from the socket. Perhaps doing so would improve performance. Reported by Tony Bigbee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21323] - Support for handling large files should be added
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=21323. 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=21323 Support for handling large files should be added [EMAIL PROTECTED] changed: What|Removed |Added Severity|Normal |Enhancement Status|NEW |ASSIGNED Priority|Other |Medium Target Milestone|--- |2.1 Final - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] 2.1 release plan
I think this is a good list for 2.1. As always I am sure more will come up, but I these are good goals. So, do we want to make this official and branch out 2.0? Mike On Monday, June 30, 2003, at 09:48 AM, Kalnichevski, Oleg wrote: All, I have taken the liberty of compiling a draft 2.1 release plan that incorporates various ideas tossed around recently (special thanks go to Eric Johnson). I feel we ought to clearly articulate our short- to mid-term development plans before 2.0 goes RC1. Comments, ideas, critique welcome Cheers Oleg RELEASE_PLAN_2_1.txt- 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: [JAKARTA NEWSLETTER DRAFT] News on 'Jakarta Commons-HttpClient' from May to June, 2003
Mike, You are the best writer (editor) on the newsletter, I think. If you would feel hesitation to write on the Apachewiki, please write the article on this Mailing list. I'll upload it. Sincerely, -- Tetsuya ([EMAIL PROTECTED]) - On Wed, 2 Jul 2003 23:01:22 -0400 (Subject: Re: [JAKARTA NEWSLETTER DRAFT] News on 'Jakarta Commons-HttpClient' from May to June, 2003) Michael Becke [EMAIL PROTECTED] wrote: Any takers on this? Mike On Wednesday, July 2, 2003, at 12:05 PM, Tetsuya Kitahata wrote: Dear Jakarta Commons-HttpClient Development Team, (http://jakarta.apache.org/commons/httpclient/) We are now preparing the 'Jakarta Newsletter Issue 9', news from May to June 2003, which would be published in the middle of July 2003. The 'Jakarta Newsletter Issue 9' will be appeared at http://jakarta.apache.org/site/news/200305.html and the editorial deadline would be 00:00 GMT, 6th July. We lowered the barrier to entry - users and developers will be able to easily contribute, as prepared the ApacheWiki(http://nagoya.apache.org/wiki/apachewiki.cgi). If you have anything to be added to the ApacheWiki, please go to http://nagoya.apache.org/wiki/apachewiki.cgi?JakartaNewsletterDrafts/ Issue9 and fill up what you want to append. If there's nothing news-worthy on 'Jakarta Commons-HttpClient', then please just write *N/A*. If you have been voted in as a new committer in 'Jakarta Commons-HttpClient' project within these 2 months, please add your name to the list on ApacheWiki. Probably, the former newsletter draft (Jakarta Newsletter Issue8) would give you some hints in writing the articles. cf. http://nagoya.apache.org/wiki/apachewiki.cgi?JakartaNewsletterDrafts/ Issue8March2003 If you have time enough to contribute to http://nagoya.apache.org/wiki/apachewiki.cgi?HttpClient please modify, fill in the ApacheWiki to create more precise and useful pages. We really appreciate your contribution. If you have any questions about this, please subscribe to mailto:[EMAIL PROTECTED] and send your messages to mailto:[EMAIL PROTECTED] Sincerely, -- Tetsuya ([EMAIL PROTECTED]) P.S. Congratulations on the release of 'HttpClient 2.0 Beta2' the other day. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
NTLM
Hello, I had a couple of notes on the HttpClient NTLM implementation that might be useful to you guys (I posted a message a couple weeks back about the NTLM documentation I put together, and have since had a chance to look over the HttpClient code): There are a few streamlining items you could apply to the Type-1 message. The flags currently specified (big-endianized, so these are backwards from the as-coded representation) are: 0x0002 Negotiate OEM (ASCII, basically) 0x0004 Request Target 0x0200 Negotiate NTLM 0x8000 Negotiate Always Sign Request Target is used for NTLMv2 authentication (to request the target's authentication realm). Negotiate Always Sign is used to request dummy signatures on the established secure session; HTTP only uses NTLM for authentication, not session security. The only flags you really need to set are Negotiate OEM (or, alternatively, Negotiate Unicode, 0x0001) and Negotiate NTLM (which is always set). Also, you don't have to include the hostname and domain in the Type-1; in fact, the server won't know that you sent them unless you also set: 0x1000 Negotiate Domain Supplied 0x2000 Negotiate Workstation Supplied The host and domain in the Type-1 message are used by the server to determine if local authentication is available (which would require native code to implement). If you factor those out, and just set the basic flags, the Type-1 message becomes a constant: 4e 54 4c 4d 53 53 50 00 // NTLMSSP\0 01 00 00 00 // Type 1 02 02 00 00 // Flags The same flags would apply in the Type-3 message, but you don't have to send them; the flags in the Type-3 aren't used in connection-oriented NTLM authentication, and older clients omit both the flags and the session key field (starting the field data at offset 52 instead of 64). Also, you might want to add a convertLong method to output a 4-byte little-endian value; while the length elements are 16-bit, the offsets are actually 32-bit values (instead of a 16-bit value padded with 2 zero bytes). Anyhow, just some thoughts; feel free to consider or ignore them as you see fit ;) Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to interrupt connexion ?
I wrote (in response to Oleg): Good idea! We could implement this in HttpClient by having one master observer thread whose job was to close a connection's socket whenever a Method using that connection has timed out. I messed with this today and got it more or less working. Since I didn't want to make any modifications to the HttpClient classes, at least for now, my timeout observer thread is just calling HttpConnection.close. It does indeed make anyone trying to read or write on the connection throw a SocketException, which turns into an HttpRecoverableException. My client code can then check to see if the timeout has elapsed and turn this into the VXML error.badfetch.timeout event if necessary. Just calling HttpConnection.close() probably isn't strictly correct. For one thing, it closes the streams before it closes the socket. If the foreground is actually doing something with the stream at the same time, this might cause an error when the stream gets closed out from under it. I think the proper sequence is to shut down the streams with Socket.shutdownInput and Socket.shutdownOutput if possible (in JDK 1.3 or later as Oleg said), then close the socket, then close the streams. To do this we'd have to add a new method to HttpConnection, maybe called abort() or some such, since there's no way to get at the socket and streams directly right now. I'll put together a patch for this and attach it to the bug when I have a chance. -- Laura - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
