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 {
/**
]
cc:
Subject:[RFE] provide request entities in a more abstract
way
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
10:47
To: Commons HttpClient Project
Subject: [RFE] provide request entities in a more abstract way
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
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
: [RFE] provide request entities in a more abstract way
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
13 matches
Mail list logo
