Curl und 404 bzw. 403

  • So, nun stehe ich da mal wieder vor einer Sache, die ich mir nicht wirklich erklären kann. Ich versuche hier per Curl auf die Webseiten meiner Kunden zuzugreifen. Möchte eigentlich nur sehen, ob die noch existieren oder nicht.

    Nun stelle ich jedoch fest, dass viele 404-Meldungen gar keine sind. Auch tauchen immer wieder 403er auf, die auch keine sind.

    Die 404 bekomme ich auf zahlreichen Domänen, vor allem aber bei allen npage.de-Seiten.

    Dachte erst, da wäre meine IP gesperrt, aber dem ist nicht so. Hab es nun schon von drei anderen versucht und auch dort kommt nur ein 404.

    Die 403 sind auch seltsam. Das sind normale Webseiten und eine davon sogar eine von einem Support-Kunden von mir - sprich, ich habe Zugriff auf das Webpaket. Auch dort kommt ein 403 ohne dass es einen Grund dafür geben würde. Allerdings konnte ich den auch umgehen, indem ich einen anderen UA verwende. Ist aber dennoch seltsam, denn der bisherige UA war ein ganz normaler und offizieller von FireFox. Nicht der neueste, aber ein ganz normaler eben.

    Hat einer eine Idee, was das genau sein kann? Die 404 konnte ich bisher noch gar nicht umgehen.

    P.S. bevor ich es vergesse. Mit fsockopen() geht es auch nicht.

    Wenn ein Mensch nicht um dich kämpft, hat er nur gewartet, dass du gehst. ;(

  • AW: Curl und 404 bzw. 403

    Kann mir das auch nur erklären dass ua oder ip Sperre drin ist. Was anderes kann es ja logischerweise net sein, gehe davon aus das curl auch bei dir installiert ist.

    Du kannst ja bei dir einstellen wie curl sich als ua meldet. Da fällt mir nicht s anderes ein....

    wenn etwas möglich erscheint mach ich das, wenn das nicht klappt gehts ans unmögliche und ansonsten das undenkbare.

    - nun stolz rauchfrei - Ich denke also Bing ich!

    Support 24h Bereitschaft 0173 6107465 - NUR Für Kunden von SEO NW!

  • Hm, also eine Sperre wäre möglich, das war ja auch mein Gedanke. Aber dann gleich auf 4 gänzlich unterschiedlichen IPs? UA kann ich bei den 404ern auch angeben was ich mag, der 404 bleibt. Bei den 403ern hat es geholfen.

    Und ja, Curl ist natürlich installiert :) Cookies werden auch angenommen und gesendet, also das läuft sonst eigentlich schon. Nur bei ca. 1000 getesteten Webseiten mit dann ca. 50 falschen 404-Meldungen bringt mir das nicht sonderlich viel. Da kann ich die ja dennoch per Hand durchsehen. Wollte das halt das System selbst machen lassen.

    Wenn ein Mensch nicht um dich kämpft, hat er nur gewartet, dass du gehst. ;(

  • hmm 404.... wie kann der denn noch kommen.. evtl eine nichtverfolgen eines 301? gibt der dann nen 404 aus?
    keine ahnung, aber an CURL kann es ja nicht so liegen, du hast ja alles richtig gemacht. also ua angepasst und das andere.

    kann das sein das ne session variable angefügt wird und das den fehler verursacht?

    wenn etwas möglich erscheint mach ich das, wenn das nicht klappt gehts ans unmögliche und ansonsten das undenkbare.

    - nun stolz rauchfrei - Ich denke also Bing ich!

    Support 24h Bereitschaft 0173 6107465 - NUR Für Kunden von SEO NW!

  • Ich habe ehrlich gesagt keine Ahnung. Ja, es gibt einen 404 per Curl und per fsockopen. Per Browser gibt es einen 200er. Session-Cookie speichere ich und sende es auch. Habe es auch schon ohne versucht, bleibt dabei.

    Das ist der Code:

    Das die Antwort:

    Cookie funktioniert auch:

    Code
    # Netscape HTTP Cookie File
    # https://beispiel.rocks/beispiel.rocks/curl.haxx.se/rfc/cookie_spec.html
    # This file was generated by libcurl! Edit at your own risk.
    
    
    xxx.npage.de	FALSE	/	FALSE	0	PHPSESSID	c833dcc6401507c0ee37b6a71cb43771

    Hab es eben mal mit einem Proxy versucht. Der kann zugreifen. Also ein allgemeiner Schutz ala Bottrap scheint das nicht zu sein.

    Wenn ein Mensch nicht um dich kämpft, hat er nur gewartet, dass du gehst. ;(

  • Wie sieht es bei Dir mit Compression Handling aus? Vll. erlauben die Pages nur gzip, dann musst Du gzip Accept-Header schicken. Sonst wird dies wohl in ein 404 enden.

    Jedenfalls sind die Content Length 0 danach aus. Ein normaler 404 hätte nämlich mehr als 0 Byte, die er als Inhalt übermittelt.

  • huch proxy geht?
    komisch..
    also nur gzip kenne ich jar net. normalerweise wird immer auch ohne gzip falls nötig gesendet. kann man zu 100% auschliessen.

    da über proxy funktioniert, würde ich auf was anderes tippen..
    komisch ist aber der 404 und nicht 403!
    würde auf ne serverseitige sperrung tippen, da bin ich mir sogar sehr sicher. sonst würde es über proxy auch nicht gehen.

    kann angehängte session sein, kann sowas wie bot-trap sein oder was anderes. mod security? oder anderes was sowas aussperren könnte.
    hast du zugriff auf phpinfo?
    evtl findet man da was. ansonsten wenn du die möglichkeit hast nachfragen was die logs serverseitig sagen..

    wenn etwas möglich erscheint mach ich das, wenn das nicht klappt gehts ans unmögliche und ansonsten das undenkbare.

    - nun stolz rauchfrei - Ich denke also Bing ich!

    Support 24h Bereitschaft 0173 6107465 - NUR Für Kunden von SEO NW!

  • Also gzip selbst habe ich versucht, war eigentlich auch anfangs mit dabei. Geht nicht. Deflate auch nicht.

    REDBot sagt z.B.:

    Web-Sniffer geht auch.

    So, eben gzip wieder aktiviert. Bleibt beim 404:

    Das scheint wohl wirklich eine Sperre zu sein. Aber schon seltsam. Ich bin hier auf 4 gänzlich unterschiedlichen Class-Netzen unterwegs. Wenn die alle gesperrt sind, warum dann die Proxys nicht? Dass ich speziell gesperrt bin scheidet eigentlich aus, denn so einen Abruf mache ich ca. alle 12-18 Monate, also das sollte nicht stören oder auffallen.

    Zugriff auf die Logs habe ich da nicht, auch nicht auf den Webspace - ist eine fremde Seite. Bei der anderen Sache mit dem 403, der durch UA-Änderung umgangen wird, habe ich Zugriff. phpinfo() sagt nichts dazu aus. Logs im Sinne von access oder error gibt es nicht, nur awstats. Das kann also auch nur was sein, was direkt vom Provider kommt, denn vom Webspace-User ist es nicht... Den verwalte ich selbst, gehört aber nicht mir.

    P.S. Wenn ich CURLOPT_RETURNTRANSFER auf 0 setze, dann bekommt ich dennoch einen 404, aber als Output die Ziffer 1.

    Aber irgendwie kann ich eine Sperre aber auch nicht recht glauben. Mache ich eine Abfrage auf npage.de, dann bekomme ich eine Antwort. Eben, dass die URL falsch ist und einen entsprechenden 301 - also keine Sperre. Rufe ich dann die www-Version ab, dann kommt wieder der 404.

    Wenn ein Mensch nicht um dich kämpft, hat er nur gewartet, dass du gehst. ;(

  • evtl wird doch CURL irgendwie identifiziert. zB wenn CURL etwas nicht "richtig" sendet.

    ich muss aber selber erstmal schauen was das sein kann..
    mir kommen da in sinn: bildschirmauflösung senden, ua ( nat, das kannste quasi auschliessen ) aber auch plugins, die evtl zwingend notwendig sind.
    weiss ich nicht, hab nur meine erfahrungen mit fail2ban und mod security die sowas auslösen könnten
    da kommt dann aber ein sauberer 403 forbidden
    der 404 muss ja auch ne ursache haben, muss ich mal gucken was CURL so mitsendet oder auch nicht.. evtl ist da das problem mit irgend nem modul oder server umgebung.. 404 ist allerdings ein wenig "mysteriös"

    wenn etwas möglich erscheint mach ich das, wenn das nicht klappt gehts ans unmögliche und ansonsten das undenkbare.

    - nun stolz rauchfrei - Ich denke also Bing ich!

    Support 24h Bereitschaft 0173 6107465 - NUR Für Kunden von SEO NW!

  • ahhhh ich hab mal was gegoogled.. 404 kommt bei curl auch wenn die anbindung nicht schnell genug ist..
    evtl mal CURL time limit hochsetzen. kann ja sein das CURL die seite aufruft und die Zeit verstrichen ist.. warum auch immer...
    kann an deinem server liegen oder die gegenstelle.

    mach mal die zeit was höher, vielleicht bringts was

    wenn etwas möglich erscheint mach ich das, wenn das nicht klappt gehts ans unmögliche und ansonsten das undenkbare.

    - nun stolz rauchfrei - Ich denke also Bing ich!

    Support 24h Bereitschaft 0173 6107465 - NUR Für Kunden von SEO NW!

  • Wenn es dann nicht mod_security ist, könnte es auch tiefer in CURL liegen. Hast Du es mal verbose Option auf der Konsole probiert?

    Könnte z.B. sein, dass die DNS falsch aufgelöst wird (IPv6 statt IPv4 und dann von Deinem Server falsch behandelt)

    @Alexa07: Ah, das hatte ich auch zuerst intutiv gedacht, hätte aber nicht vermutet, dass CURL dann ein 404 ausgibt sondern einen vernünftigen Error...

  • Timeout ist auszuschließen. Der 404 kommt sofort, Zeit ist in Sekunden gar nicht messbar ;)

    Ist auch so, wenn der Timeout kommt, dann meldet das Curl als Fehler per curl_error(). Status-Code ist in dem Fall dann auch 0. Auf der Console habe ich es noch nicht versucht, das wäre mal eine Idee.

    Wenn ein Mensch nicht um dich kämpft, hat er nur gewartet, dass du gehst. ;(

  • So, per Console wird es auch nicht besser:

    Wenn ein Mensch nicht um dich kämpft, hat er nur gewartet, dass du gehst. ;(

  • genauso :(

    Wenn ein Mensch nicht um dich kämpft, hat er nur gewartet, dass du gehst. ;(

  • Nachtrag. Eine serverseitige IP-Sperre wird immer unverständlicher... Wie gesagt, 301-Meldungen gehen, erst dann kommt der 404. Eben mal mit der robots.txt versucht, da kommt sofort der korrekte 200er!

    Und dann gleich noch mit einer echten Fehlerseite. Auch die ist plausibel. Content-Länge passt und Content selbst kommt auch:

    Wenn ein Mensch nicht um dich kämpft, hat er nur gewartet, dass du gehst. ;(

  • huch jetzt weiss ich aber auch nimmer..
    so ne sperrungen kann ich mir net erklären. Hab ja selten mal mod security drauf, der sendet aber einen 403. kann also daran nicht liegen.
    404 kann ich mir nur mit einem timeout erklären, kannst du das wirklich auschliessen?
    andere sachen wären identifizierung von CURL, wie auch immer.
    Wieviel % macht denn der 404 aus?
    Würde mich mal interessieren worans liegt. Arbeite ja auch mit CURL, hab sowas aber noch nicht erlebt.

    wenn etwas möglich erscheint mach ich das, wenn das nicht klappt gehts ans unmögliche und ansonsten das undenkbare.

    - nun stolz rauchfrei - Ich denke also Bing ich!

    Support 24h Bereitschaft 0173 6107465 - NUR Für Kunden von SEO NW!

  • Zitat

    404 kann ich mir nur mit einem timeout erklären, kannst du das wirklich auschliessen?


    Ja, 100%.

    URL steht doch oben. Das ist bei allen npage-Seiten, also auch bei der https://beispiel.rocks/beispiel.rocks/www.npage.de selbst ;)

    Zitat

    Wieviel % macht denn der 404 aus?


    Bei meinen Kunden allgemein, egal wo und was: ca. 1%
    Bei npage-Seiten: 100% aber ohne robots.txt, echte Fehlerseiten etc. Also 100% der normalen Seiten, die eigentlich einen 200er liefern sollten.

    Wenn ein Mensch nicht um dich kämpft, hat er nur gewartet, dass du gehst. ;(