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=27242.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
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=27242.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
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=27242.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Providing only an InputStream as a request body is not enough. We can
not automatically repeat such a request since we are unable to reset the
input stream without buffering it. I suggest we introduce an abstraction
for the source of request entities such as:
interface RequestEntity {
/**
Hello Odi,
is this meant as an extension or as a replacement for
directly passing the InputStream? In the second case,
I would add something like isRepeatable() to handle cases
where it is indeed not possible to read the data twice.
I'd prefer an explicit check to some exception being
thrown from
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=27242.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
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=27242.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Something similar to SAX InputSource would be quite handy I think.
http://java.sun.com/j2se/1.4.2/docs/api/org/xml/sax/InputSource.html
However, I'd wait with this feature until 4.0
Oleg
-Original Message-
From: Ortwin Glück [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 26, 2004
Kalnichevski, Oleg wrote:
Something similar to SAX InputSource would be quite handy I think.
The SAX InputSource was exactly where I got the idea from. But I don't
like the (heavy) way of doing things of that class. I really prefer a
(simple) interface. It is then up to the user how he wants
Roland Weber wrote:
Hello Odi,
is this meant as an extension or as a replacement for
directly passing the InputStream?
It is meant to replace the direct passing of the InputStream. We would
need to remove that method. Deprecation is possible with an internal
wrapper that just throws an
From: Ortwin Glück
Sent: Thursday, February 26, 2004 6:27 AM
To: Commons HttpClient Project
Subject: Re: [RFE] provide request entities in a more abstract way
In the second case,
I would add something like isRepeatable() to handle cases
where it is
indeed not possible to read the data
Rezaei, Mohammad A. wrote:
This is a bad idea. The HTTP RFC (2616) explicitly forbids auto retries:
Non-idempotent methods or sequences
MUST NOT be automatically retried, although user agents MAY offer a
human operator the choice of retrying the request(s).
So if retries are not good, then
Both authentication and closed connections should occur long before we read
the input stream to send the request body. So why would you want to reset
the stream?
Thanks
Moh
-Original Message-
From: Ortwin Glück [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 26, 2004 9:56 AM
To:
Besides, currently PostMethod can accept three different types of objects as request
entity source: String, InputStream, NameValuePair[]. As a result PostMethod has got to
do at times very error-prone input objects juggling. It would be much easier and
cleaner to deal with just one interface
Rezaei, Mohammad A. wrote:
Both authentication and closed connections should occur long before we read
the input stream to send the request body. So why would you want to reset
the stream?
Thanks
Moh
Well, no.
Authentication failures are only reported by an HTTP status code AFTER
the whole
Hello Moh,
you are assuming preemptive authentication.
In general, authentication is triggered by a 40x
response from the server, which means the
request has already been sent.
best regards,
Roland
Rezaei, Mohammad A. [EMAIL PROTECTED]
26.02.2004 15:57
Please respond to Commons HttpClient
However, I'd wait with this feature until 4.0
Are you sure? What is the reason for not including it in 3.0?
Odi,
No particular reason. It just 'feels' like 4.0 feature to me. If you come up with a
patch, of course, there's no reason of what so ever not to include it into 3.0.
I agree a
I see. If we limit the retries to 401 and 407, we're safe, per the RFC:
401:
The client MAY repeat the
request with a suitable Authorization header field
407:
The
client MAY repeat the request with a suitable Proxy-Authorization
header field
Most of the other 40x are fatal and should
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=27237.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
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=27242.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
import org.apache.commons.httpclient.*;
import
org.apache.commons.httpclient.methods.GetMethod;
import
org.apache.commons.httpclient.methods.PostMethod;
import
org.apache.commons.httpclient.cookie.CookiePolicy;
import java.io.IOException;
public class Test4 {
public static void
21 matches
Mail list logo
