2013-04-10 6 views
6

Ich habe mehrere URLs, die in allen Browsern einwandfrei funktionieren, aber wenn ich versuche, den Seiteninhalt mit Get() des Indy Http-Clients zu erhalten, gibt es Fehlercode 500, interner Serverfehler. Dies ist mit dem neuesten Indy SVN Build (4981).Warum gibt Indy Project HttpClient Get() Code 500 für einige URLs, die in Webbrowsern funktionieren?

Hier ist mein Beispielcode. Alles, was dazu benötigt wird, ist Delphi mit Indy-Komponenten und ein Formular mit einer Schaltfläche und einem Memo.

procedure TForm1.Button1Click(Sender: TObject); 
var HTTPCLIENT1: TIdHTTP; 
begin 
    try 
    try 
    HTTPCLIENT1 := TIdHTTP.Create(nil); 
    Memo1.Clear; 
    with HTTPCLIENT1 do 
    begin 
      HandleRedirects := True; 
      Request.UserAgent := 'Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.7.3) Gecko/20040924 Epiphany/1.4.4 (Ubuntu)'; 
      Memo1.Text := Get('http://www.laredoute.fr/vente-machine-a-coudre-bernette-20-kit-couture--garantie-2-ans.aspx?productid=401225048&documentid=999999&categoryid=22918417&customertarget=0&offertype=0&prodcolor=1#pos=33_n_n_n_n_n_n&numberpage=2'); 
      Caption := ResponseText; 
    end; 
    except 
    On e: Exception do 
    begin 
      Memo1.Lines.Add('Exception: '+e.Message); 
    end; 
    end; 
    finally 
    HTTPCLIENT1.Free; 
    end; 
end; 

Es ist kein Verbindungsproblem auf meiner Seite, da 99% der URLs 200 oder 404 zurückgeben, nur wenige Rückkehr 500, aber jeder Browser öffnet sie fein in einer Sekunde.

+0

Gibt es auf den URLs Umleitungen geschieht, die fehlschlagen? –

+0

Völlig irrelevant, aber Ihre Userentent-Zeichenkette (Gecko 1.7.3, die in Firefox 0.10 verwendet wurde) kann dazu führen, dass einige Websites versuchen, unterschiedliche Inhalte zu liefern (passend für ältere Browser). –

Antwort

10

Diese Art von Fehler schlägt normalerweise vor, dass die Anforderung GET in irgendeiner Weise fehlerhaft ist, was dazu führt, dass der Servercode an seinem Ende fehlschlägt. Aber ohne zu sehen, wie der Webbrowser tatsächlich aussieht, um ihn mit den Anforderungen von TIdHTTP zu vergleichen, gibt es keine Möglichkeit, sicher zu wissen, was der Server nicht mag.

aktualisieren: aber was ich sehe, passiert ist, dass, wenn ein Web-Browser die URL anfordert, der Server sofort eine 200-Antwort zurückschickt, wenn TIdHTTP die URL anfordert, sendet der Server eine 301 zu einer neuen URL umleiten, die dann sendet eine 302-Weiterleitung an eine Fehlerseite, wenn TIdHTTP diese URL anfordert, die dann die 500-Antwort sendet, wenn TIdHTTP diese URL anfordert.

Die beiden Unterschiede zwischen einer Web-Browser Anfrage und der anfänglichen TIdHTTP Anfrage, die Auswirkungen auf einem Webserver haben würde, sind:

  1. die URL, die Sie mit TIdHTTP fordern enthält einen Anker-Tag am Ende (alles nach die # Zeichen - #pos=33_n_n_n_n_n_n&numberpage=2) welche Webbrowser normalerweise ausziehen würden. Anker sind nicht Teil von URLs. Sie sind für Webbrowser gedacht, um Punkte in Daten zu finden, die von einer URL abgerufen werden.

  2. der Benutzer Agent. Einige Webserver reagieren auf verschiedene Benutzeragenten und können unterschiedliche Antworten an verschiedene Arten von Benutzeragenten senden.

Als ich den Anker aus der URL zu entfernen, TIdHTTP.Get() stürzt nicht mehr ab:

Memo1.Text := Get('http://www.laredoute.fr/vente-machine-a-coudre-bernette-20-kit-couture--garantie-2-ans.aspx?productid=401225048&documentid=999999&categoryid=22918417&customertarget=0&offertype=0&prodcolor=1'); 
+0

Ich habe gerade 3 weitere Browser getestet, 2 mobile und eine sehr alte VM mit IE6. Die URL wurde gut angezeigt. Wenn mein Code in Ordnung ist, ist das vielleicht ein Indy-Bug? – Casady

+0

Ich dachte, Indy analysiert Anker, bevor er irgendeine Anfrage macht, nicht wahr? – Casady

+1

Es entfernt derzeit keine Anker aus URLs. Dieser Gedanke ist mir vor ein paar Minuten aufgefallen. TIdHTTP sollte das tun, also werde ich es in Kürze aktualisieren. –