DO NOT REPLY [Bug 25264] - Cookie rejected

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: DO NOT REPLY [Bug 16881] - migrate to commons-codec Base64

On Tue, 2004-01-06 at 21:30, Michael Becke wrote: > Hi Oleg. Welcome back. > Hi Mike. Yeah, I am back and feel like committing a patch or two ;-) > I think we also need to add commons-codec to project.xml. > You are right. Good catch. Will correct this in a sec Oleg > Mike --

Re: DO NOT REPLY [Bug 16881] - migrate to commons-codec Base64

Hi Oleg. Welcome back. I think we also need to add commons-codec to project.xml. Mike On Jan 6, 2004, at 3:18 PM, [EMAIL PROTECTED] wrote: DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT

RE: upload large files- Filepart

that is correct unfortunately I have had the "privilege" to work on a webserver which is "supposed" to be 1.1 compliant.. I am trying hard to get them to support the 100-expect continue at the same time I want to see if I can get a work around.. and hence the mails!! --- "Kalnichevski, Oleg" <[E

DO NOT REPLY [Bug 16881] - migrate to commons-codec Base64

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: upload large files- Filepart

> This problem seems like it is the perfect candidate for the > ExpectContinueMethod.setUseExpectHeader() function. Isn't this exactly > the scenario for which this header was intended? True. The catch is that some HTTP servers do not adequately support 'expect-continue' handshake, which is ex

Re: upload large files- Filepart

This problem seems like it is the perfect candidate for the ExpectContinueMethod.setUseExpectHeader() function. Isn't this exactly the scenario for which this header was intended? -Eric Oleg Kalnichevski wrote: Siddhartha, I believe the solution to this problem is trivial. All it takes is ch

RE: SSL problem on HPUX

> Can you shed any light on the different behavior in Windows vs > HPUX? Not that it will change anything, but I like to learn why these things > behave the way they do to prevent future time wasting activities. I have had no exposure to HPUX of what so ever, so I may only be guessing here. I h

Re: upload large files- Filepart

Kalnichevski, Oleg wrote: Can you give me more details as to why you think this may cause problems with HTTP pipelining? It won't if done right :-) You just need to make sure that you are monitoring the response corresponding to the request and not any other response from previously pipelined r

RE: upload large files- Filepart

Odi, Can you give me more details as to why you think this may cause problems with HTTP pipelining? I am a bit skeptical, as the approach I outlined simply follows the recommendation of the HTTP spec: 8.2.2 Monitoring Connections for Error Status Messages An HTTP/1.1 (or later) client sendi

Re: upload large files- Filepart

Oleg Kalnichevski wrote: Siddhartha, I believe the solution to this problem is trivial. All it takes is checking for availability of a response from the target server prior to sending each consecutive chunk of request body. A premature response from the target server detected before the request