> You cannot always trust the Size property of a stream.
Err...OK
> That is not quite correct, because that will also clear any custom headers
> you may want to set.
> Cookies, Accept-encoding and so on.
Exactly what I have in mind, just need to document it somewhere.
Anyway, the default shou
On Tue, 20 Jan 2015, leledumbo wrote:
Because the header may have been set on purpose by the user.
Even if the actual data sent is not of the same length?
You cannot always trust the Size property of a stream.
I will look at a mechanism to remove headers that were 'automatically'
added
> Because the header may have been set on purpose by the user.
Even if the actual data sent is not of the same length?
> I will look at a mechanism to remove headers that were 'automatically'
> added.
How about a property ClearHeadersOnEachRequest (defaults to true for
backward compatibility)?
On Sun, 18 Jan 2015, leledumbo wrote:
Yes, I can. The TFPHTTPClient instance is not stateless.
Before doing a call, some headers are added to the request headers if they
are not there yet.
For example, the Content-Size header.
But the Content-Size header is not added if is already present.
F
> Yes, I can. The TFPHTTPClient instance is not stateless.
>
> Before doing a call, some headers are added to the request headers if they
> are not there yet.
> For example, the Content-Size header.
>
> But the Content-Size header is not added if is already present.
> For calls 1 and 2 it doe
On Sun, 18 Jan 2015, leledumbo wrote:
i was thinking that there's some sort of inbound traffic that may be
filling a
buffer that needs to be emptied... i don't know or have any other ideas to
offer...
Mmm...could be, that's what should be searched for.
The problem is not in TFPHTTPClient.
> i was thinking that there's some sort of inbound traffic that may be
filling a
buffer that needs to be emptied... i don't know or have any other ideas to
offer...
Mmm...could be, that's what should be searched for.
> The problem is not in TFPHTTPClient. The problem is the data and/or URL
> fo
On Fri, 16 Jan 2015, leledumbo wrote:
Consider the following program (it's a real program with real parameters,
nothing hidden, so you can really just try it out because the target server
is public):
The problem is not in TFPHTTPClient. The problem is the data and/or URL for
request 3:
if
On 1/17/2015 12:42 PM, leledumbo wrote:
you don't have to clear the inbound buffer to prevent constipation? ;)
Which inbound buffer?
i was thinking that there's some sort of inbound traffic that may be filling a
buffer that needs to be emptied... i don't know or have any other ideas to offer
> you don't have to clear the inbound buffer to prevent constipation? ;)
Which inbound buffer?
--
View this message in context:
http://free-pascal-general.1045716.n5.nabble.com/Cannot-reuse-TFPHTTPClient-object-for-2-different-POST-requests-tp5720779p5720788.html
Sent from the Free Pascal - G
On 1/16/2015 12:57 PM, leledumbo wrote:
Consider the following program (it's a real program with real parameters,
nothing hidden, so you can really just try it out because the target server
is public):
you don't have to clear the inbound buffer to prevent constipation? ;)
--
NOTE: No off-list
Consider the following program (it's a real program with real parameters,
nothing hidden, so you can really just try it out because the target server
is public):
{$mode objfpc}{$H+}
uses
fphttpclient;
var
HTTP: TFPHTTPClient;
begin
HTTP := TFPHTTPClient.Create(nil);
WriteLn('Response
12 matches
Mail list logo
