Kleine Indy 10 Http Client Warnung bezüglich UserAgent

[Shark99]

Ich habe eben mehrere Stunden nach einem Crash in meiner App gesucht.
Dabei ist der Http Client bei einer bestimmten URI in einer Endlosschleife steckengeblieben.

Das Problem betrifft nur die Version aus dem SVN, also Indy 10 Build 4915.

Indy 10 Build 3962 in einer anderen VM hat das Problem nicht, verhält sich aber merkwürdig.

Hier ist der Code:

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
var HTTPCLIENT1: TIdHTTP;
begin
  try
   try
     HTTPCLIENT1 := TIdHTTP.Create(nil);
     HTTPCLIENT1.Request.UserAgent := 'Mozilla/3.0 (compatible; Test)';
     Memo1.Text := HTTPCLIENT1.Get(('http://www.grecehotels.com/favicon.ico'));
   except
     On e: Exception do
          Memo1.Text := 'Exception: '+e.Message;
   end;
  finally
     HTTPCLIENT1.Free;
  end;
end;

Indy 10 Build 4915 hängt wie gesagt in einer Endlosschleife (was ganz Böse in einem Thread sein kann, weil der nicht mehr ansprechbar ist).

Eine Änderung des Code auf den Default User Agent:

Delphi-Quellcode:

HTTPCLIENT1.Request.UserAgent := 'Mozilla/3.0 (compatible; Indy Library)';

behebt das Problem - es gibt ein HTTP/1.1 403 Forbidden zurück.

Indy 10 Build 3962 verhält sich auch etwas merkwürdig.

Delphi-Quellcode:

HTTPCLIENT1.Request.UserAgent := 'Mozilla/3.0 (compatible; Indy Library)';

ergibt ein HTTP/1.1 403 Forbidden,

wohingegen

Delphi-Quellcode:

HTTPCLIENT1.Request.UserAgent := 'Mozilla/3.0 (compatible; Test)';

ein HTTP/1.1 404 Not Found liefert, was zwar nicht korrekt, aber allemal besser
als eine Endlosschleife ist! :)

[Shark99]

Und hier gleich die Lösung um die Schleife zu vermeiden und statt dessen ein (falsches) 404 bekommen (sollte ja 403 sein).

IdGlobalProtocols.pas

Delphi-Quellcode:

function ParseHTTPMetaEquiveData(const AStr : String; var VPos : Integer;
  const ALen : Integer) : String;  {$IFDEF USE_INLINE}inline;{$ENDIF}
var
  LQuoteChar : Char;
  LWord : String;
begin
  Result := '';
  DiscardDocWhiteSpace(AStr, VPos, ALen);
...
  repeat
    DiscardDocWhiteSpace(AStr, VPos, ALen);
...
    if AStr[VPos] = '=' then begin {do not localize}
      Inc(VPos);
      DiscardDocWhiteSpace(AStr, VPos, ALen);
      if CharIsInSet(AStr, VPos, HTML_QUOTECHARS) then begin
        LQuoteChar := AStr[VPos];
        Inc(VPos);
        if TextIsSame(LWord, 'CONTENT') then begin
          Result := Result + ' ' + ParseUntil(AStr, LQuoteChar, VPos, ALen);
        end else begin
          DiscardUntil(AStr, LQuoteChar, VPos, ALen);
        end;
        Inc(VPos);
      end else begin
        if TextIsSame(LWord, 'CONTENT') then begin
          Result := Result + ' ' + ParseUntilCharOrEndOfTag(AStr, ' ', VPos, ALen); {do not localize}
        end else begin
          DiscardUntilCharOrEndOfTag(AStr, ' ', VPos, ALen); {do not localize}
        end;
      end;
    end;
    Inc(VPos); // ********************** NEUER CODE ***********************
  until False;
end;

[mjustin]

Wie sieht denn die HTTP Response aus, bei der Indy in die Endlosschleife gerät?

IdGlobalProtocols ParseHTTPMetaEquiveData wurde im September 2011 geändert, in Revision 4676.
Den Fix für das Problem kann man zum Beispiel im Atozed Indy Forum posten:

http://forums2.atozed.com/viewforum.php?f=7

Und es gibt zum Thema Endlosschleife dort auch einen Thread:

http://forums2.atozed.com/viewtopic....iveData#p26664

[Shark99]

Nachdem ich mir länger den ganzen Code angeschaut hab rate ich dringend ab ParseHTTPMetaEquiveData überhaupt zu verwenden.

Das geht mit HTTPCLIENT1.HTTPOptions := HTTPCLIENT1.HTTPOptions + [hoNoParseMetaHTTPEquiv];

Der Parse Code ist unheimlich langsam. Statt eines PChars zu verwenden, wird in der Funktion ein String indexiert, was in Delphi extrem langsam ist.

Z.B. bei dieser URI http://www.lesnumeriques.com/telecom...le-n23923.html werden (mit Code 200 OK) 120 KB Html Daten geliefert. Indy braucht dann fast eine Minute auf einem Core i7 um das durchzuparsen (mit PChar sicher in <1 Sekunde möglich). 1 Minute nach meinem Fix (ohne den Fix geht es ja unendlich lang, weil repeat nie verlassen wird).

[Shark99]

Meine erste Annahme war falsch.

Also der Bericht über den Bug (inkl Fix), und der Sacheverhalt mit dem langsamen Parser ist korrekt, allerdings verhält sich die User Agent Geschichte anders.

Der Default User Agent der Indy Lib, also Mozilla/3.0 (compatible; Indy Library) ist blacklisted auf einigen Servern, deshalb kommt 403 zurück. Ändert man ihn auf etwas anderes, dann kommt 404, was korrekt ist.

[geskill]

Hey,
hatte selber gerade noch eine kleine Anpassung der Routine vorgeschlagen.

Aber auf dieser Webseite musst du mal schauen, ein User schreibt im Beitrag im body-Teil einen HTML-Header (Topic unique du produit). Das ist es was Indy zum "verrecken" bringt ;)
Eine Sinnvolle und Einfache Lösung ist da echt schwierig. Weil bis zum "</head" möchte ich das auch nicht gehen lassen, weil einige auch noch meta-Tags im body haben, die viele Browser auch noch fressen und script-Tags die ja mit der gleichen Routine gelesen werden - wären dann davor auch betroffen. :/

Grüße

PS: Das mit dem UserAgent ist normal; ich empfehle einfach den von einem gut genutztem Browser zu nehmen.