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?
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: redirects not allowed for PostMethod
Matt, I went through the same thing a week or two ago. Thing is, what method should the PostMethod use for the redirect? You need to capture the result and issue a GET using the Location response header attribute. David Matthew S. Ring wrote: Hi, I just started using the latest version of the HTTPClient to screen-scrape from Rational Clear Quest. Unfortunately, CQ expects POSTed requests and responds with a redirect. IE and Mozilla-based browsers seem OK with that, but the HTTPClient refuses to follow redirects after a POST, due to stated conflicts with RFC 2616. Is this stringency really neccesary? Selfishly, it would be nice if I could just turn off this bit of compliance checking with a boolean flag. Opinions? Thanks. -Matthew Ring - 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: AW: post redirect
Thomas, I'd like to hear more about this because I don't understand how the browser can do that. I know if the form requires POST, the browser simply can't issue GET and expect it to work. Hmm, are you saying that the browser just looks in the response header and issues a GET to follow the redirect? OK, I would expect something along those lines David [EMAIL PROTECTED] wrote: I am with you Oleg! Some times ago I had the same "problem" but it figured out that the browsers follow the redirects not within the PostMethod but they instead execute a GetMethod. If they wouldn't do so the client could have an wrong url "displayed". Gtx, Thomas -Ursprüngliche Nachricht- Von: Kalnichevski, Oleg [mailto:[EMAIL PROTECTED] Gesendet: Freitag, 7. März 2003 17:39 An: Commons HttpClient Project Betreff: RE: post redirect David HttpClient is a library, whereas a browser is a totally different kind of beast. RFC 2616 says the following: "... If the 301 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued ..." A well-behaving browser should provide the end user with a confirmation dialog or a configuration option to automatically perform POST redirects. HttpClient can't have that luxury, as it is not supposed to be directly interacting with the end user. I am personally convinced that POST redirect should be handled by the application that consumes Httpclient's services. All it basically takes is a retry loop Does anyone see that differently? Cheers Oleg -Original Message- From: David Kavanagh [mailto:[EMAIL PROTECTED] Sent: Freitag, 7. März 2003 17:24 To: [EMAIL PROTECTED] Subject: post redirect I've been working with httpclient for a couple of days to build a Cocoon transformer that helps me build pipelines to navigate web sites and extract data. I've read the parts of RFC2616 that deal with redirects and state they are automatic on the client only for GET and HEAD methods. I know the JDC and a web site I wrote use POST for the login form and issue a redirect as a response. Any browser I've tried this with honors the redirect. I can send some test code I've been using to test the automated login (that includes handling cookies). Anyway, I've observed browsers honoring the redirect on a POST, can't httpclient be configured that way? Looking at the source code tells me no. (I've been using 2.0 alpha 3). Thanks, David - 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: post redirect
Thanks, While I see your point, I also didn't see any nice way to do this without yanking a bunch of code out of HttpMethodBase.java and pasting it into my application. I'd really like the option of overriding the default behaviour to keep my code simpler. Make sense? I've developing enough years to have seen the tradeoffs between making it "perfect" and making it work. I know you are trying to be true to the RFC, but I've found that with the web, there are always exceptions! Regards, David Kalnichevski, Oleg wrote: David HttpClient is a library, whereas a browser is a totally different kind of beast. RFC 2616 says the following: "... If the 301 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued ..." A well-behaving browser should provide the end user with a confirmation dialog or a configuration option to automatically perform POST redirects. HttpClient can't have that luxury, as it is not supposed to be directly interacting with the end user. I am personally convinced that POST redirect should be handled by the application that consumes Httpclient's services. All it basically takes is a retry loop Does anyone see that differently? Cheers Oleg -Original Message- From: David Kavanagh [mailto:[EMAIL PROTECTED] Sent: Freitag, 7. März 2003 17:24 To: [EMAIL PROTECTED] Subject: post redirect I've been working with httpclient for a couple of days to build a Cocoon transformer that helps me build pipelines to navigate web sites and extract data. I've read the parts of RFC2616 that deal with redirects and state they are automatic on the client only for GET and HEAD methods. I know the JDC and a web site I wrote use POST for the login form and issue a redirect as a response. Any browser I've tried this with honors the redirect. I can send some test code I've been using to test the automated login (that includes handling cookies). Anyway, I've observed browsers honoring the redirect on a POST, can't httpclient be configured that way? Looking at the source code tells me no. (I've been using 2.0 alpha 3). Thanks, David - 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]
post redirect
I've been working with httpclient for a couple of days to build a Cocoon transformer that helps me build pipelines to navigate web sites and extract data. I've read the parts of RFC2616 that deal with redirects and state they are automatic on the client only for GET and HEAD methods. I know the JDC and a web site I wrote use POST for the login form and issue a redirect as a response. Any browser I've tried this with honors the redirect. I can send some test code I've been using to test the automated login (that includes handling cookies). Anyway, I've observed browsers honoring the redirect on a POST, can't httpclient be configured that way? Looking at the source code tells me no. (I've been using 2.0 alpha 3). Thanks, David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
