idhttp gibt 500 internal server error zurück

NOS1971 · Verfasst: Do 18.07.13 22:04

Hallo,

ich code grad eine analysesoftware für webseiten und stelle nun fest das mir das idhttp.get bei standard urls wie domain.de/impressum ohne parameter etc. einen 500 internal server error ausgibt .... die seite ist aber über einen browser einfach zu erreichen ...

woran kann das liegen ? ... hier der auszug aus dem code -> default user agent ist bei mir 'Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2; Trident/6.0)'

Benötige ich Wartezeiten zwischen dem Get der einzelnen Threads ?

markieren

Delphi-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:
30:
31:
32:
33:
34:
35:
36:
37:
38:
39:
40:

 // create idhttp
 idHTTP := TIdHTTP.Create(nil);
 // idhttp basic settings
 idHTTP.HandleRedirects := true;
 idHTTP.RedirectMaximum := 50;
 // create stream for source
 URLSource := TStringStream.Create;

 ......

    try
    // prepare idhttp
    idHTTP.Response.Clear;
    idHTTP.Request.Clear;
    idHTTP.ReadTimeout := 5000;
    idhttp.Request.UserAgent := sDefaultUserAgent;
    // prepare stream
    URLSource.Clear;
    URLSource.Position := 0;
    // get source via http
    try
     if (FItem.URLType <> uttext) then
      idHTTP.Head(TIdURI.URLEncode(FItem.URLString))
     else
      idHTTP.Get(TIdURI.URLEncode(FItem.URLString),URLSource);
    except
     on E: Exception do
     begin
      // an error occured getting the source
      URLSource.Clear;
     end;
    end;
    // add idhttp infos to the data structure
    FItem.HTTPStatus := idHTTP.Response.ResponseCode;
    FItem.HTTPStatusText := idHTTP.Response.ResponseText;
    FItem.RedirectCount := idHTTP.Rsponse.RedirectCount;
    FItem.Server := idHTTP.Response.Server;
    FItem.ContentType := idhttp.Response.ContentType;

  ....

Grüße und Danke,
Andreas

Einloggen, um Attachments anzusehen!

NOS1971 · Verfasst: So 21.07.13 16:50

Niemand eine Idee ? Bin wirklich ratlos. Muss ich für jedes Get eine neue idHTTP erzeugen oder ist es ok wie ich das mache jede abfrage in dem thread darüber laufen zu lassen ? Auf nem Form ist das ja ok wenn ich das so mache. Ist das vielleicht im Thread ein Problem ?

Hidden · Verfasst: So 21.07.13 20:07

Hallo Andreas,

Ich hatte nach deinem Post einmal Google bemüht, aber für idhttp error 500 nur Fälle gefunden, in denen Server den falschen Fehlercode ausgeben um Bots/Scripte zu verwirren. Wenn sonst niemand weiter weiß, kann ich nur weitergeben was andernorts geraten wurde (kenne mich mit indy selbst nicht aus):

Zitat:

> One thing you probably should check is to see if the ISAPI really is
> returning the proper response code. The reason I mention that is there
> was a case where someone was testing HTTP post with a server and he
> thought it was a bug in Indy because Internet Explorer and Netscape had
> success with the post. It turned out that the server was always giving
> the response code 500 (internal error) followed by the results of the
> successful query.

Nach dem was man sonst noch so lesen konnte, steht das query-result dann in error.Msg / error.Message / o.ä.

Grüße,
Daniel

_________________
Centaur spears can block many spells, but no one tries to block if they see that the spell is a certain shade of green. For this purpose it is useful to know some green stunning hexes. (HPMoR)

NOS1971 · Verfasst: So 21.07.13 20:36

ich habe mir nun ein memo gemacht im hauptform wo ich mir alle exceptions und die dazugehörigen urls listen kann ... aber ich finde wirklich nichts sinniges warum das so ist

Gibt es alternativen zu Indy mit denen man arbeiten kann um auch das Umfeld an Infos zu kriegen welche im Header stehen ?

Einloggen, um Attachments anzusehen!

jaenicke · Verfasst: So 21.07.13 20:58

Du kannst Wireshark benutzen um die Anfrage und Antwort durch den Browser mit deiner aus dem Programm zu vergleichen.

NOS1971 · Verfasst: So 21.07.13 21:11

jaenicke hat folgendes geschrieben :

Du kannst Wireshark benutzen um die Anfrage und Antwort durch den Browser mit deiner aus dem Programm zu vergleichen.

Wireshark kannte ich noch nicht ... super ... da werde ich gleich mal mit auf die suche gehen ... mal wieder -> Danke Sebastian :-)

Wie Du siehst habe ich das mit dem Threading schon gut im Griff und mit dem VT gehts auch aufwärts :-)

NOS1971 · Verfasst: So 21.07.13 21:32

Also soweit ich das sehe sind es tatsächlich 500er Fehler ... die werden auch von indy so reported ... gibt es einen sinnvollen grund dafür ?

jaenicke · Verfasst: So 21.07.13 21:57

Viel interessanter ist was an der Anfrage anders ist. Denn der Server reagiert ja nur auf die Anfrage und da es im Browser geht, muss es da einen Unterschied geben. Ob das der User Agent ist oder z.B. ein Pfadtrennzeichen am Ende oder so etwas, solltest du im Vergleich der Anfragen sehen können.

// EDIT:
Cookies könnten auch ein Grund sein, die du im Browser hast. Dann bräuchtest du einen Cookiemanager für TIdHttp und müsstest die Unterseiten mit den selben Cookiedaten aufrufen.

Hidden · Verfasst: So 21.07.13 22:23

Soweit ich las, zeigen Browser die Seite trotzdem noch an wenn vom Server ein falscher Fehlercode ausgegeben wird. Insofern wäre es auch möglich, dass der Server in beiden Fällen gleich reagiert?

Vielleicht mal ein anderes Projekt suchen das indy verwendet und in diesem die Seite aufrufen?

_________________
Centaur spears can block many spells, but no one tries to block if they see that the spell is a certain shade of green. For this purpose it is useful to know some green stunning hexes. (HPMoR)

jaenicke · Verfasst: So 21.07.13 22:36

Hidden hat folgendes geschrieben :

Soweit ich las, zeigen Browser die Seite trotzdem noch an wenn vom Server ein falscher Fehlercode ausgegeben wird. Insofern wäre es auch möglich, dass der Server in beiden Fällen gleich reagiert?

Auch das sollte ja in Wireshark zu sehen sein. Das Entscheidende ist der Vergleich der Anfragen und der Antworten, jeweils insgesamt, nicht nur die Antwortcodes.

NOS1971 · Verfasst: Mo 22.07.13 10:53

Hier mal der Vergleich der beiden GET's ... ist das nu das problem eines cookies oder woran kann das liegen ... allzuviel kann ihc daraus auch nicht entnehmen

Anfrage des Programmes:

markieren

Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:

GET /news-blog/news/194-webseiten-update-vom-17-05-2011 HTTP/1.1
Host: modellbau-portal.net
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding: identity
User-Agent: Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2; Trident/6.0)
Cookie: f7cbd4fedbd0ce0015f50e154ce532cd=3b3c1c11477d09a5e4f514e6bc844bba

HTTP/1.1 500 Internal Server Error
Date: Mon, 22 Jul 2013 08:30:24 GMT
Server: Apache
Content-Length: 608
Connection: close
Content-Type: text/html; charset=iso-8859-1

Anfrage durch den Browser:

markieren

Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:

GET /news-blog/news/194-webseiten-update-vom-17-05-2011 HTTP/1.1
Host: modellbau-portal.net
Connection: keep-alive
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.72 Safari/537.36 AlexaToolbar/alxg-3.1
Accept-Encoding: gzip,deflate,sdch
Accept-Language: de-DE,de;q=0.8,en-US;q=0.6,en;q=0.4
Cookie: fbm_160626110711281=base_domain=.modellbau-portal.net; f7cbd4fedbd0ce0015f50e154ce532cd=5cc87045f1fc1763f0b1648b5d89c138; __unam=6cb5566-13f51a0fd42-1929fd7b-127

HTTP/1.1 200 OK
Date: Mon, 22 Jul 2013 08:48:07 GMT
Server: Apache
P3P: CP="NOI ADM DEV PSAi COM NAV OUR OTRo STP IND DEM"
Content-Encoding: gzip
X-Content-Encoded-By: Joomla! 2.5
Cache-Control: no-cache
Pragma: no-cache
Content-Length: 19600
Connection: close
Content-Type: text/html; charset=utf-8

Yogu · Verfasst: Mo 22.07.13 11:29

Hallo,

das ist seltsam. Ich habe gerade exakt deine Anfrage an den Server geschickt (mit telnet), und die korrekte Antwort bekommen:

markieren

Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:

GET /news-blog/news/194-webseiten-update-vom-17-05-2011 HTTP/1.1
Host: modellbau-portal.net
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding: identity
User-Agent: Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2; Trident/6.0)
Cookie: f7cbd4fedbd0ce0015f50e154ce532cd=3b3c1c11477d09a5e4f514e6bc844bba

HTTP/1.1 200 OK
Date: Mon, 22 Jul 2013 09:27:27 GMT
Server: Apache
P3P: CP="NOI ADM DEV PSAi COM NAV OUR OTRo STP IND DEM"
Cache-Control: no-cache
Pragma: no-cache
Content-Length: 86528
Connection: close
Content-Type: text/html; charset=utf-8

Kannst du den Fehler immer noch reproduzieren?

Grüße,
Yogu

NOS1971 · Verfasst: Mo 22.07.13 11:47

Ja .... ist immer noch reproduzierbar .... das war aber nur eine von unzähligen urls die diesen fehler schmeissen ...

Hab auch nochmal die aktuelle exe von mir rangehangen ... nach dem durchlauf stehen alle in der list und die idhttp exceptions in dem exception-tab

markieren

Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:

GET /news-blog/news/194-webseiten-update-vom-17-05-2011 HTTP/1.1
Host: modellbau-portal.net
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding: identity
User-Agent: Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2; Trident/6.0)

HTTP/1.1 500 Internal Server Error
Date: Mon, 22 Jul 2013 09:39:48 GMT
Server: Apache
Content-Length: 608
Connection: close
Content-Type: text/html; charset=iso-8859-1

Einloggen, um Attachments anzusehen!

Yogu · Verfasst: Mo 22.07.13 12:29

Kann dein Programm leider nicht testen, anscheinend funktioniert es unter Wine nicht richtig. Es hat gar keine Netzwerkaktivität, und im Exception-Tab steht einfach nur "IDHTTP EXCEPTION - - (hostname)".

Was mir noch eingefallen ist: Vielleicht machst du zu viele Requests in kurzer Zeit. Hast du schon mal probiert, nur die URL aufzurufen, die den Fehler wirft, statt sie beim Crawlen aufzurufen? Und du könntest noch schauen, ob die Anfrage wirklich an den richtigen Server geht (also ob die IP-Adresse in Wireshark stimmt).

Hidden · Verfasst: Mo 22.07.13 12:33

Yogu hat folgendes geschrieben :

Vielleicht machst du zu viele Requests in kurzer Zeit. Hast du schon mal probiert, nur die URL aufzurufen, die den Fehler wirft, statt sie beim Crawlen aufzurufen?

Klingt wahrscheinlich:

Hidden hat folgendes geschrieben :

nur Fälle gefunden, in denen Server den falschen Fehlercode ausgeben um Bots/Scripte zu verwirren.

_________________
Centaur spears can block many spells, but no one tries to block if they see that the spell is a certain shade of green. For this purpose it is useful to know some green stunning hexes. (HPMoR)

NOS1971 · Verfasst: Mo 22.07.13 13:51

Hi,

also wenn ich es genau betrachte scheint es wohl so zu sein das nach einiger zeit einfach dicht gemacht wird vom server aus ... und das scheinbar bei contentseiten also text/html ...

nun frage ich mich ... wie machen das andere crawler denn dann wenn das zuviele anfragen sind oder in zu schneller reihenfolge ?

Xenu Linksleuth funzt auch mit der Page und das sieht da so aus:

markieren

Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:

GET /news-blog/news/194-webseiten-update-vom-17-05-2011 HTTP/1.1
Accept: */*
User-Agent: Xenu Link Sleuth/1.3.8
Host: modellbau-portal.net
Cache-Control: no-cache

HTTP/1.1 200 OK
Date: Mon, 22 Jul 2013 11:01:24 GMT
Server: Apache
P3P: CP="NOI ADM DEV PSAi COM NAV OUR OTRo STP IND DEM"
Cache-Control: no-cache
Pragma: no-cache
Set-Cookie: f7cbd4fedbd0ce0015f50e154ce532cd=092d5e974f2605e3ee3e9a29de4305d1; path=/
Content-Length: 86097
Connection: close
Content-Type: text/html; charset=utf-8

2. Beispiel einer Anfrage ... kam auch ok zurück

GET /allgemeines/ausstellungsverzeichnis/category/plz-80000-89999-2 HTTP/1.1
Accept: */*
User-Agent: Xenu Link Sleuth/1.3.8
Host: modellbau-portal.net
Cache-Control: no-cache

Wenn ich es bei mir hardcode funzt es auch:

markieren

Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:

GET /news-blog/news/194-webseiten-update-vom-17-05-2011 HTTP/1.1
Host: modellbau-portal.net
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding: identity
User-Agent: Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2; Trident/6.0)

HTTP/1.1 200 OK
Date: Mon, 22 Jul 2013 11:47:11 GMT
Server: Apache
P3P: CP="NOI ADM DEV PSAi COM NAV OUR OTRo STP IND DEM"
Cache-Control: no-cache
Pragma: no-cache
Set-Cookie: f7cbd4fedbd0ce0015f50e154ce532cd=2aee863745804f7db5282783b801cd5f; path=/
Content-Length: 86529
Connection: close
Content-Type: text/html; charset=utf-8

Hidden · Verfasst: Mo 22.07.13 14:01

Wenn der Server die Daten sonst nicht rausrücken will, musst du wohl die Anfragen pro Sekunde einschränken:
In einem Timer (Interval = ?) eine noch zu ermittelnde, erlaubte Anzahl an Anfragen senden bis alles abgecrawlt ist.

_________________
Centaur spears can block many spells, but no one tries to block if they see that the spell is a certain shade of green. For this purpose it is useful to know some green stunning hexes. (HPMoR)

NOS1971 · Verfasst: Mo 22.07.13 14:12

Hmmm .... also ich denke es muss was anderes sein ... Linksleuth macht auch die ganze seite ohne intervall und am stück superfix ... wüßte nicht warum der das dürfte und ich nicht ...

oder kann es sein das der useragent mich ja als browser ausgibt und es unnatürlich wäre so schnell die seiten zu wechseln ...???? ----

Update: ... also am useragent lag es nicht

Hidden · Verfasst: Mo 22.07.13 15:21

NOS1971 hat folgendes geschrieben :

Hmmm .... also ich denke es muss was anderes sein ... Linksleuth macht auch die ganze seite ohne intervall und am stück superfix ... wüßte nicht warum der das dürfte und ich nicht ...

Hast du den Quelltext angesehen? Kann durchaus sein, dass das Intevall so kurz ist dass du es nicht merkst.

Vermutlich wird die Anfrage verzögert noch einmal gesendet, wenn sie nicht erfolgreich war.

_________________
Centaur spears can block many spells, but no one tries to block if they see that the spell is a certain shade of green. For this purpose it is useful to know some green stunning hexes. (HPMoR)

NOS1971 · Verfasst: Mo 22.07.13 15:29

Also wenn ich im Thread nach jeder Analyse eines Items eine Sleep(5000) mache dann habe ich trotz allem bei 100 Threads immer noch 500er Fehler .... ich checke das mal mit 10 threads und 10 sekunden

Wie wäre es wenn ich den UserAgent automatisch wechseln lasse nach jedem get und aus ner liste von 10 AgentsStrings auswähle ?

	Mitgliederliste
	Gruppen
	Das Team
	Richtlinien
	Synonyme