[FIXED] HTTP response code wrong (lNet client)

[tjones]

Hello,

I noticed that the LNET visual LHTTPClientComponent doesn't seem to update the HTTP Response Code (200/404/403/500). I tried all different events, including OnError of course. It keeps reporting back the very first status code it received during runtime, even though the URI has changed and disconnect/re-connect took place. This also happens if the same URI suddenly doesn't exists anymore (I provoked a 404 error). It's never changing from 200 => 404 or vice versa 404 => 200.

Code: [Select]

procedure TForm1.LHTTPClientComponent1DoneInput(ASocket: TLHTTPClientSocket);
var
    status: string;
begin
    status := IntToStr(HTTPStatusCodes[ASocket.ResponseStatus]);
    lblStatus.Caption := status;
end; 

Can somebody confirm this please? Or am I doing something wrong here?

Thanks!

lNET 0.6.5
Lazarus-0.9.31-31796-fpc-2.4.4-20110725-win32.exe

[Shebuka]

Try to process status code iside ProcessHeader

Code: [Select]

procedure THTTPClient.MyProcessHeaders(ASocket: TLHTTPClientSocket);
begin
  if HTTPStatusCodes[ASocket.ResponseStatus] = 200 then
    FFileExist := True
  else
    FErrors.Add('Response: ' + IntToStr(HTTPStatusCodes[ASocket.ResponseStatus]) + ' ' + ASocket.ResponseReason);
  FResponse := HTTPStatusCodes[ASocket.ResponseStatus];
end;

[tjones]

As I said: I DID try this in all standard events:

OnInput,OnDoneInput,OnProcessHeaders,OnError,OnCanWrite

It shows the same WRONG return code in all those events from the second Connect/SendRequest. But I must correct myself, I was wrong, sorry: The OnError event doesn't return the HTTP response code (aSocket: TLSocket), at least I couldn't find out how to do it.

[UPDATE] I tried under Windows XP and Windows 2000, also before with older Lazarus 0.9.29 + lNET version 0.6.2 [/UPDATE]

Looks like a bug to me...

[tjones]

Nobody who can verify this error?

[tjones]

Hard to believe that nobody noticed or reported this MAJOR bug in lNET so far, and no-one of the 200+ readers here seems to be able/interested to replicate this error in the past 2 weeks. Quite sad...

Anyway, today I digged deeper into this myself. The problem lies here:

\components\lnet\lib\lhttp.pp

Code: [Select]

2126 procedure TLHTTPClientSocket.ParseLine(pLineEnd: pchar);
2127 begin
2128   if FError <> ceNone then
2129     exit;
2130
2131   if FResponse^.Status = hsUnknown then
2132   begin
2133     ParseStatusLine(pLineEnd);
2134     exit;
2135   end;
2136
2137   inherited;
2138 end;

This causes the status only being read *ONCE* during runtime as FResponse^.Status is NEVER being reset. Pretty bad I though, so let's fix it:

Code: [Select]

2071 procedure TLHTTPClientSocket.SendRequest;
2072 var
2073   lMessage: TStringBuffer;
2074   lTemp: string[23];
2075   hasRangeStart, hasRangeEnd: boolean;
2076 begin
2077   lMessage := InitStringBuffer(504);
2078   FResponse^.Status := hsUnknown; // <== This works
2079   AppendString(lMessage, HTTPMethodStrings[FRequest^.Method]);
....
2123   WriteBlock;
2124 end;

I just inserted the above line in SendRequest(), resetting the status BEFORE every new request that is being send. No matter what kind of error occurs thereafter - the status will always be 'fresh' and up-to-date now, showing all HTTP status changes (after URI has changed, document disapperead, server error etc).

Note that the line numbers can be slightly different for you, depending on the version of your lNet sources.

@Almindor
You did a great job, but I would also recommend to make the TIMEOUT work on this component. I read your statement in another thread, but I disagree. What sense does it make if it's there, but doesn't work and can't be used? It DOES make sense for developers having a proper timeout for this control, it's a very basic feature that you'll find in every other blocking/networking control in commercial products (even in Visual Basic). In my application I had to implement my own timeout routine now where lNet is running in 3 different threads that I distroy after a given time. This is just awkward as it could be so simple...

[felipemdc]

You could try to contact Almindor by e-mail so that he can merge this fix. (I dont know his e-mail, might be in the wiki, should be in the mailling list archives)

[Almindor]

I'm monitoring this and am very glad you took the time to look into the issue. There are two main problems atm. first is that I have very little time, second is that this code is Micha's territory.

I'll try to look into it and apply your patch if Micha approves.