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
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 twice
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
To: Commons HttpClient Project
Subject: Re: [RFE] provide request entities in a more abstract way
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
implemented by various classes
Oleg
-Original Message-
From: Ortwin Glück [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 26, 2004 15:56
To: Commons HttpClient Project
Subject: Re: [RFE] provide request entities in a more abstract way
Rezaei, Mohammad A. wrote:
This is a bad idea
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
Project
To: 'Commons HttpClient Project'
[EMAIL PROTECTED]
cc:
Subject:RE: [RFE] provide request entities in a more
abstract way
Both authentication and closed connections should occur long before we
read
the input stream to send the request body. So why
-weight (interface) approach is better in this case
Oleg
-Original Message-
From: Ortwin Glück [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 26, 2004 12:17
To: Commons HttpClient Project
Subject: Re: [RFE] provide request entities in a more abstract way
Kalnichevski, Oleg wrote
]
26.02.2004 15:57
Please respond to Commons HttpClient Project
To: 'Commons HttpClient Project'
[EMAIL PROTECTED]
cc:
Subject:RE: [RFE] provide request entities in a more
abstract way
Both authentication and closed connections should occur long before we
read
12 matches
Mail list logo