On Fri, 25 Apr 2014, silvioprog wrote:
2014-04-25 10:24 GMT-03:00 Michael Van Canneyt <mich...@freepascal.org>:
On Fri, 25 Apr 2014, silvioprog wrote:
2014-04-25 3:39 GMT-03:00 Michael Van Canneyt
<mich...@freepascal.org>:
[...]
Damn windows returning 0 on read... Can you please test with
the following change:
Procedure FillBuffer;
Var
R : Integer;
begin
SetLength(FBuffer,ReadBufLen);
Repeat
r:=FSocket.Read(FBuffer[1],ReadBufLen);
If r<0 then
Raise EHTTPServer.Create(SErrReadingSocket);
if R=0 then
Sleep(10);
Until (R<>0);
if (R<ReadBuflen) then
SetLength(FBuffer,r);
end;
After apply this change, now when read returns 0, it freezes the app.,
because the "sleep(10)" command is infinitely called. :/
OK, what we can do is add a timeout:
Procedure FillBuffer;
Const
MaxReadRetries = 150;
Var
R,C : Integer;
begin
C:=0;
SetLength(FBuffer,ReadBufLen);
Repeat
r:=FSocket.Read(FBuffer[1],ReadBufLen);
If r<0 then
Raise EHTTPServer.Create(SErrReadingSocket);
if R=0 then
begin
Sleep(10);
Inc(C);
end;
Until (R<>0) or (C>MaxReadRetries);
if (R<ReadBuflen) then
SetLength(FBuffer,r);
end;
It will then try 150 times, and then error out.
BUT, reading this:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms740121%28v=vs.85%29.aspx
"If the connection has been gracefully closed, the return value is zero."
So, this means then thay the original implementation is correct. You just need
to catch the error using the OnRequestError handler...
Sorry for my ignorance, but, would not it be better to read the HTTP data only if
the client is still connected or if read bytes > 0?
Yes and no.
Yes in the sense that you have a more 'clean' experience.
No, because it IS an error condition (client went away unexpectedly) and you
should be aware of it.
I will make it a property that is settable: 'IgnoreLostConnections' or so.
Michael.
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal