Art der Meldung und Status

[pl]

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.

[Tabellenkalk]

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

[pl]

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

[Mitleser]

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.

[pl]

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

[Mitleser]

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

[pl]

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

[Mitleser]

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!

[pl]

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

[Mitleser]

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.

[pl]

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

[dedlfix]

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.

[pl]

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

[dedlfix]

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.

[Mitleser]

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.

[pl]

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 😉

[Mitleser]

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

[pl]

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 😉

[pl]

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 😉

[Regina Schaukrug]

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.")

[pl]

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

[Regina Schaukrug]

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?

[pl]

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

[Regina Schaukrug]

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.

[pl]

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 😉

[Mitleser]

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"?

3. 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.

4. Andere Möglichkeiten?

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

Zusatzfrage: ist das eigentlich ein Doppelpost?

[pl]

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

[pl]

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