pl: Art der Meldung und Status

problematische Seite

Hi,

die problematische Seite antwortet mit einem Status 400 wenn der Request Parameter enthält. Ich habe mich für diesen Status entschieden, weil diese Seite nicht dafür vorgesehen ist, Parameter zu verarbeiten, denn die Seite ist nicht interaktiv. Fragen:

  1. Noch eine Meldung an den Benutzer einbauen?
  2. Wenn (1) die ganze Response in text/plain?
  3. verstehen Suchmaschinen den og. Status so wie ich den meine?
  4. Andere Möglichkeiten?

Bitte mal um Hinweise, danke und Grüße.

  1. problematische Seite

    Hallo,

    die problematische Seite antwortet mit einem Status 400 wenn der Request Parameter enthält.

    ist es denn wirklich ein clientseitiges Problem?
    Was hältst du von 501?

    Gruß
    Kalk

    1. problematische Seite

      Hallo,

      die problematische Seite antwortet mit einem Status 400 wenn der Request Parameter enthält.

      ist es denn wirklich ein clientseitiges Problem?

      Ein Problem ist es ursprünglich nicht, aber der Client wird auf eine Art und Weise interaktiv die nicht vorgesehen ist und somit durchaus als Bad Request eingestuft werden kann.

      Was hältst du von 501?

      Darüber hab ich auch schon nachgedacht. Not Implemented trifft ja gleichermaßen zu. Ich habe das jetzt zentral organisiert und kann das ggf. noch ändern.

      Danke für Deinen Hinweis! MfG

      1. problematische Seite

        die problematische Seite antwortet mit einem Status 400 wenn der Request Parameter enthält. ist es denn wirklich ein clientseitiges Problem?
        Ein Problem ist es ursprünglich nicht, aber der Client wird auf eine Art und Weise interaktiv die nicht vorgesehen ist und somit durchaus als Bad Request eingestuft werden kann.

        Stell Dir mal vor, Du bewirbst dieses "handwerkzeugs.de/man" und willst Deinen Werbepartnern Provisionen bei Vertragsabschluss ausschütten. Ne Idee, wie die URL dann evtl. aussieht?

        Richtisch:

        http://handwerkzeugs.de/man?partnerID=4711

        Ist die Seite jetzt lt. Deiner Definition interaktiv? Nö. Stattdessen ist sie jetzt ein Bad Request.

        LOL

        Würdest Du korrekte Canonicals setzen, hättest Du das Problem erst gar nicht. Aber Hauptsache mal wieder was eigenes gebastelt.

        1. problematische Seite

          die problematische Seite antwortet mit einem Status 400 wenn der Request Parameter enthält. ist es denn wirklich ein clientseitiges Problem?
          Ein Problem ist es ursprünglich nicht, aber der Client wird auf eine Art und Weise interaktiv die nicht vorgesehen ist und somit durchaus als Bad Request eingestuft werden kann.

          Stell Dir mal vor, Du bewirbst dieses "handwerkzeugs.de/man" und willst Deinen Werbepartnern Provisionen bei Vertragsabschluss ausschütten. Ne Idee, wie die URL dann evtl. aussieht?

          Richtisch:

          http://handwerkzeugs.de/man?partnerID=4711

          Falsch. Sowas würde ich völlig anders lösen, nämlich mit den Möglichkeiten die gerade mein FW hierzu hat. Auf gar keinen Fall würde da eine PartnerID im URL erscheinen!

          Würdest Du korrekte Canonicals setzen, hättest Du das Problem erst gar nicht. Aber Hauptsache mal wieder was eigenes gebastelt.

          Es geht hier nicht um Kanonische URLs sondern um Bad Request. Und die können sich auch aus POST Parametern ergeben. MfG

          1. problematische Seite

            Stell Dir mal vor, Du bewirbst dieses "handwerkzeugs.de/man" und willst Deinen Werbepartnern Provisionen bei Vertragsabschluss ausschütten. Ne Idee, wie die URL dann evtl. aussieht? Richtisch: http://handwerkzeugs.de/man?partnerID=4711 Falsch. Sowas würde ich völlig anders lösen, nämlich mit den Möglichkeiten die gerade mein FW hierzu hat. Auf gar keinen Fall würde da eine PartnerID im URL erscheinen!

            Die Antwort habe ich erwartet :-) Ich werde einen Teufel tun, mich dazu auf eine fachliche Diskussion mit Dir einzulassen, ist auch nicht so wichtig.

            Viel entscheidender ist die Frage: warum sollte ein Partnerprogramm sich darauf einlassen, sich an Deinen Lösungsweg zu halten, obwohl die schon längst ein etabliertes System haben, was genau so arbeitet und bei zigtausend Kunden im Einsatz ist?

            Nein, ein Rolf Rost sagt dann: nee Leute, mit euch will ich keinen Umsatz machen, weil mein Framework bei so einem Unfug nämlich mit Bad Request antwortet, jawollja!

            LOL

            1. problematische Seite

              Nein, ein Rolf Rost sagt dann: nee Leute, mit euch will ich keinen Umsatz machen, weil mein Framework bei so einem Unfug nämlich mit Bad Request antwortet, jawollja!

              Blödpolemik. Wenn ein Partner seine ID im URL sehen will, dann kriegt er das auch. Wenn das so programmiert bzw. konfiguriert ist, dann ist das auch kein Bad Request.

              Aber eine PartnerID im URL abzubilden ist ein bischen sehr laienhaft. Das verleidet ja förmlich zu unerwünschten Aktivitäten.

              Ich werde einen Teufel tun, mich dazu auf eine fachliche Diskussion mit Dir einzulassen, ist auch nicht so wichtig.

              Ja, schon klar daß Du hier nur rumstänkern willst. Du wirst jedoch von mir stets fachlich korrekte Anworten bekommen -- nichts anderes!

              MfG

              1. problematische Seite

                Aber eine PartnerID im URL abzubilden ist ein bischen sehr laienhaft. Das verleidet ja förmlich zu unerwünschten Aktivitäten.

                Ja, klar, stimmt. Ich (Mitleser) könnte statt mit meiner PartnerID "4711" die Leute mit einer fremden PartnerID "4712" (Mitstänkerer) auf Deine Seite schicken, damit jemand anderes am Umsatz beteiligt wird. Sorry, diese Sicherheitslücke / Gefahr war mir so nicht bewusst.

                Vielen Dank für den Hinweis!

                1. problematische Seite

                  Aber eine PartnerID im URL abzubilden ist ein bischen sehr laienhaft. Das verleidet ja förmlich zu unerwünschten Aktivitäten.

                  Ja, klar, stimmt. Ich (Mitleser) könnte statt mit meiner PartnerID "4711" die Leute mit einer fremden PartnerID "4712" (Mitstänkerer) auf Deine Seite schicken, damit jemand anderes am Umsatz beteiligt wird. Sorry, diese Sicherheitslücke / Gefahr war mir so nicht bewusst.

                  Solche Gefahren kennen viele nicht, die dann Backends entwicklen die mit derselben ID arbeiten (z.B. beim Zugriff aus das Konto des Partners). Selbst Google macht den Fehler und gibt hier z.b. POST /geolocation/v1/geolocate?key=AIzaSyD_Drzahe4dBzGCZ9ArvowCvrPx_yFrlCM HTTP/1.1 einen Key preis den eigentlich gar keiner kennen darf.

                  MfG

                  1. problematische Seite

                    Aber eine PartnerID im URL abzubilden ist ein bischen sehr laienhaft. Das verleidet ja förmlich zu unerwünschten Aktivitäten. Ja, klar, stimmt. Ich (Mitleser) könnte statt mit meiner PartnerID "4711" die Leute mit einer fremden PartnerID "4712" (Mitstänkerer) auf Deine Seite schicken, damit jemand anderes am Umsatz beteiligt wird. Sorry, diese Sicherheitslücke / Gefahr war mir so nicht bewusst. Solche Gefahren kennen viele nicht [...]

                    Hinweis für mich: Sarkasmus gegenüber Hotti deutlich schärfer formulieren, damit er ihn als solchen auch erkennt.

                    1. problematische Seite

                      Hinweis für mich: Sarkasmus gegenüber Hotti deutlich schärfer formulieren, damit er ihn als solchen auch erkennt.

                      Auf Deinen Sarkasmus können wir hier -- wir befinden uns in einem Fachforum -- verzichten. MfG

                      1. problematische Seite

                        Tach!

                        Auf Deinen Sarkasmus können wir hier -- wir befinden uns in einem Fachforum -- verzichten.

                        Könnten wir. Wollen wir aber nicht. Wer auch immer "wir" ist …

                        dedlfix.

                        1. problematische Seite

                          Ah schön daß Du auch hier bist. Hast Du was zu meiner ursprünglichen Frage beizutragen? Das Thema hatte wir ja schonmal hier (um 2011), da hattest Du auch schon keine Lösung. MfG

                          1. problematische Seite

                            Tach!

                            Ah schön daß Du auch hier bist. Hast Du was zu meiner ursprünglichen Frage beizutragen?

                            Nichts was nicht bereits gesagt wurde. Wenn es ein serverseitiges Problem ist, dann 5xx, wenn es der Client verursacht hat, dann 4xx.

                            dedlfix.

              2. problematische Seite

                Ja, schon klar daß Du hier nur rumstänkern willst.

                Nanana! Ich formuliere hier durchaus scharf / frech, weil es mir angebracht erscheint, ja. Ein wenig Spaß macht es mir auch, sonst hätte ich überhaupt nichts dazu geschrieben, weil absehbar war, wohin das führt. Dennoch: von "nur rumstänkern" kann keine Rede sein. Einfach nochmal lesen, ja?

                Du wirst jedoch von mir stets fachlich korrekte Anworten bekommen -- nichts anderes!

                Ja genau. Stets fachlich korrekt. Sicher das. Ich finde es ja durchaus amüsant, aber eigentlich ist es traurig, dass Du das selbst glaubst. Niemand (ich wiederhole: niemand) kann stets fachlich korrekte Antworten geben.

                Menschen, die so ticken, sind potentiell gefährlich.

        2. problematische Seite

          Hi,

          Stell Dir mal vor, Du bewirbst dieses "handwerkzeugs.de/man" und willst Deinen Werbepartnern Provisionen bei Vertragsabschluss ausschütten. Ne Idee, wie die URL dann evtl. aussieht?

          Richtisch:

          http://handwerkzeugs.de/man?partnerID=4711

          Ist die Seite jetzt lt. Deiner Definition interaktiv? Nö. Stattdessen ist sie jetzt ein Bad Request.

          Nö. Der URL kriegt interface=partnerprogram und fertisch.

          LOL

          Freu Dich 😉

          1. problematische Seite

            Ist die Seite jetzt lt. Deiner Definition interaktiv? Nö. Stattdessen ist sie jetzt ein Bad Request. Nö. Der URL kriegt interface=partnerprogram und fertisch.

            Aaah! Statt also jede URL per Default "Partnerprogrammtauglich" zu haben, konfigurierst Du das pro Fall einzeln. Clever!

            LOL

            1. problematische Seite

              Ist die Seite jetzt lt. Deiner Definition interaktiv? Nö. Stattdessen ist sie jetzt ein Bad Request. Nö. Der URL kriegt interface=partnerprogram und fertisch.

              Aaah! Statt also jede URL per Default "Partnerprogrammtauglich" zu haben, konfigurierst Du das pro Fall einzeln. Clever!

              Oh mann, Dein Logik ist ätzend. Selbstverständlich kann ich das auch zentral konfigurieren. Dafür gibt es einen default-Block.

              LOL

              Selber 😉

    2. problematische Seite

      Hallo,

      die problematische Seite antwortet mit einem Status 400 wenn der Request Parameter enthält.

      ist es denn wirklich ein clientseitiges Problem?
      Was hältst du von 501?

      Habs überschlafen. 501 Not Implemented wäre auch OK, aber wenn das auf eine unzulässige Benutzereingabe zurückzuführen ist, dann ist 400 schon der richtige Responsestatus. Und es ist immer auf eine unzulässige Benutzereingabe zurückzuführen. Es sei denn, der Programmierer hatte die Absicht, einen 501 Not Implemented auszugeben.

      Schöne Grüße 😉

    3. problematische Seite

      ist es denn wirklich ein clientseitiges Problem?

      Durchaus. Wenn clientseitig Uri gebastelt werden, die nicht vorgesehen sind…

      Andere Beispiele für serverseitige Antworten auf unwillkommene Clientanfragen wären

      • 409 (Bad Request)
      • 403 (Forbidden) (dazu würde ich neigen)
      • 409 (Policy Not Fulfilled)
      • 423 (Locked)
      • 424 (Failed Dependency)

      Meine Lieblingskandidaten sind aber

      • 404 (NOT Found - für Honeypots),
      • 402 (Payment Required - Angreifer verarschen),
      • 418 (I am a Teepot - "Du denkst wohl ich bin blöd.")

      und:

      • 204 (No Content - "Nö. Du bekommst keine Antwort.")
      1. problematische Seite

        Hi,

        und den Text dazu? In text/plain oder in text/html? Wichtig ist ja auch, bezüglich eines von 200 abweichenden Status, daran zu denken wie die Suchmaschinen damit umgehen.

        MfG

        1. problematische Seite

          und den Text dazu? In text/plain oder in text/html?

          Geschmackssache, außer bei 204 (No Content). Kein Content wird weder codiert noch hat dieses Nichts einen Mime-Type.

          Wichtig ist ja auch, bezüglich eines von 200 abweichenden Status, daran zu denken wie die Suchmaschinen damit umgehen.

          Soweit ich weiß nimmt Google & Co. alles, was nicht mit Status 200 kommt, auch nicht in das Listing auf. Soll doch so sein - oder bedeutet "Statuscodes für unwillkommene Clientanfragen" dass ich noch mehr davon haben möchte?

          1. problematische Seite

            und den Text dazu? In text/plain oder in text/html? Geschmackssache, außer bei 204 (No Content). Kein Content wird weder codiert noch hat dieses Nichts einen Mime-Type.

            Also ich denke, man sollte wenistens das Hauptmenu zeigen. Also text/html.

            Wichtig ist ja auch, bezüglich eines von 200 abweichenden Status, daran zu denken wie die Suchmaschinen damit umgehen.

            Soweit ich weiß nimmt Google & Co. alles, was nicht mit Status 200 kommt, auch nicht in das Listing auf. Soll doch so sein - oder bedeutet "Statuscodes für unwillkommene Clientanfragen" dass ich noch mehr davon haben möchte?

            Ich habe keine Ahnung wie Bots mit Status 400 umgehen. Deswegen frage ich ja. Jedenfalls verbleiben auch Seiten mit Status 404 sehr lange im Goggle Index. MfG

            1. problematische Seite

              Ich habe keine Ahnung wie Bots mit Status 400 umgehen.

              Ich weiß es genau: Jeder Bot reagiert darauf so wie der Programmierer es wissentlich oder unbedacht vorgesehen hat.

              Geschmackssache, außer bei 204 (No Content). Kein Content wird weder codiert noch hat dieses Nichts einen Mime-Type.

              Also ich denke, man sollte wenistens das Hauptmenu zeigen. Also text/html.

              Den Status 204 No Content und dann auch nur irgendwas als Payload zu senden ist widersprüchlich. Ich verwende das bei Brut-Force-Geschichten um den ausgehenden Datenverkehr zu minimieren. Geht es weiter landet je nach meinen Rechten auf dem System die Adresse in der .htaccess oder in der Blocklist der Firewall.

              1. problematische Seite

                Den Status 204 No Content und dann auch nur irgendwas als Payload zu senden ist widersprüchlich.

                Das ist klar. Dafür kann man den Header-Block mal so richtig knackevoll beladen 😉

  2. problematische Seite

    die problematische Seite antwortet mit einem Status 400 wenn der Request Parameter enthält.

    Ah, so versuchst Du jetzt deine kaputten Canonicals zum umschiffen. Interessant, Du legst Wert auf Individualität!

    Ich habe mich für diesen Status entschieden, weil diese Seite nicht dafür vorgesehen ist, Parameter zu verarbeiten

    Wenn sie es es denn wäre, dann müsstest Du den Status konsequenterweise auch werfen, sobald nur ein Paramter nicht Deinen Richtlinien entspricht. Viel Freude bei der Implementation!

    denn die Seite ist nicht interaktiv.

    Die Gleichung "Parameter = interaktiv" scheint mir schwierig. Was ist z.B. mit "/kochrezepte?page=2", "/kochrezepte?page=3"... ist das auch "interaktiv"?

    1. verstehen Suchmaschinen den og. Status so wie ich den meine?

    Ich gehe mal schwer davon aus, dass HTTP 400 nicht in den Index wandern wird, wenn Du darauf hinaus wolltest.

    1. Andere Möglichkeiten?

    Meta robots noindex + Canonicals, aber das wäre ja langweilige best practice ;-)

    Zusatzfrage: ist das eigentlich ein Doppelpost?

    1. problematische Seite

      die problematische Seite antwortet mit einem Status 400 wenn der Request Parameter enthält.

      Ah, so versuchst Du jetzt deine kaputten Canonicals zum umschiffen. Interessant, Du legst Wert auf Individualität!

      Mit canonical hat das gar nichts zu tun.

      Ich habe mich für diesen Status entschieden, weil diese Seite nicht dafür vorgesehen ist, Parameter zu verarbeiten

      Wenn sie es es denn wäre, dann müsstest Du den Status konsequenterweise auch werfen, sobald nur ein Paramter nicht Deinen Richtlinien entspricht. Viel Freude bei der Implementation!

      Dafür gibt es eine Parameter-Kontrollstruktur und für Seiten die diese nicht durchlaufen eine Attribut no_param, das wird zentral übers FW abgefangen.

      denn die Seite ist nicht interaktiv.

      Die Gleichung "Parameter = interaktiv" scheint mir schwierig. Was ist z.B. mit "/kochrezepte?page=2", "/kochrezepte?page=3"... ist das auch "interaktiv"?

      Selbstverständlich. In dem Moment wo ich das einem Benutzer anbiete ist es interaktiv und Interaktion auch erwünscht. Wenn Besucher jedoch von selbst auf die Idee kommen, irgendwelche Parameter anzuhängen, ist das nicht erwünscht und auch nicht vorgesehen.

      Ich gehe mal schwer davon aus, dass HTTP 400 nicht in den Index wandern wird, wenn Du darauf hinaus wolltest.

      Genau. Ich setze einen Status, weil ich nicht davon ausgehe, daß Suchmaschinen eine Fehlermeldung wie "Unbekannter Parameter im Request" verstehen. Meine interaktiven Seiten melden das ja schon, nur halt ohne den Status.

      Danke für Deinen Beitrag. MfG

    2. problematische Seite

      die problematische Seite antwortet mit einem Status 400 wenn der Request Parameter enthält.

      Ah, so versuchst Du jetzt deine kaputten Canonicals zum umschiffen. Interessant, Du legst Wert auf Individualität!

      Eher auf Korrektheit. Ich habe das jetzt so erweitert, daß die canonischen Links ohne Parameter verbleiben auch dann wenn Parameter nicht erwünscht sind. Ebenso verbleibt der Status. Aus Deiner Sicht wären dann meine canonischen Links nicht mehr kaputt und das vereinbart sich nun auch mit konsolidierten Abläufen in meinem FW was jeden URL als eine Anwendung betrachtet.

      Du kümmerst Dich, ich kümmere mich. So halten es die Franzosen (der ich meiner Herkunft nach auch bin).

      MfG