Status Code für Ferienabwesenheit

[Beat]

Hallo

Welches wäre der richtige http Status Code
für eine URL, die gültig ist,
die aber zwischenzeitlich nicht bedient wird
(zum Beispiel, weil die Seite wegen Abwesenheit der Admins nicht verfügbar ist).

Mit dem Statuscode sollte auch die normale Seite, allerdings verändert im Content, ausgeliefert werden. Zum Beispiel, um eben diese Nachricht mitzuteilen.
Bots sollten diese Seite in diesem Zustand nicht indexieren.

mfg Beat

[suit]

503 Service Unavailable könnte passen - ist aber eigentlich für kurzfristige technische Unerreichbarkeiten gedacht.

[LX]

Außerdem ist 503 ein Fehlercode, aber hier liegt schließlich kein Fehler vor. Dass Du im Urlaub bist, gehört eher in den Last-Modified-Headercode als in den Status.

Gruß, LX

[Tim Tepaße]

Welches wäre der richtige http Status Code für eine URL, die gültig ist,
die aber zwischenzeitlich nicht bedient wird

Das nächste wäre noch 503 Service Unavailable. Du kannst auch eigene Fehlercodes erfinden oder bei bestehenden Fehlercodes eine eigene Reason-Phrase angeben, kannst aber nicht damit rechnen, dass Clients das dann beherrschen.

Bots sollten diese Seite in diesem Zustand nicht indexieren.

Google tut dies bei 503 nicht. Vielleicht empfiehlt sich aber trotzdem noch eine Robot Anweisung für andere Suchmaschinen.

[Beat]

Welches wäre der richtige http Status Code für eine URL, die gültig ist,
die aber zwischenzeitlich nicht bedient wird

Das nächste wäre noch 503 Service Unavailable.

Grenzwertig. Mittels Umleitungen hat man ja HTTP für die Ferien, aber das Protokoll sieht HTTP IN den Ferien nicht vor.
Der Grenzfall ist, dass die 500er auf einen Servererror hinweisen. Die 400er aber eigentlich für den Content zuständig sind.

Du kannst auch eigene Fehlercodes erfinden oder bei bestehenden Fehlercodes eine eigene Reason-Phrase angeben, kannst aber nicht damit rechnen, dass Clients das dann beherrschen.

Ja das kommt unbeabsichtigt bei mir ab und zu vor.

Google tut dies bei 503 nicht. Vielleicht empfiehlt sich aber trotzdem noch eine Robot Anweisung für andere Suchmaschinen.

Ja das ist doch was.
Ich meine, für zwei Wochen die roobots.txt manipulieren, geht ja. Aber für jeden Sa/So in der Woche?
Da kommt auf die Disallow-Verwaltung der Bots nicht mehr mit.

Ich denke, ich müsste LX' Vorschlag näher unter die Lupe nehmen.

mfg Beat

[ChrisB]

Hi,

Welches wäre der richtige http Status Code
für eine URL, die gültig ist,
die aber zwischenzeitlich nicht bedient wird
(zum Beispiel, weil die Seite wegen Abwesenheit der Admins nicht verfügbar ist).

Was an dem Request kann denn nicht wie normal behandelt werden, weil der Admin nicht da ist?

Mit dem Statuscode sollte auch die normale Seite, allerdings verändert im Content, ausgeliefert werden. Zum Beispiel, um eben diese Nachricht mitzuteilen.

Das klingt für mich so, als ob die Nichtverfügbarkeit rein inhaltlicher Natur ist.
Dann lautet der Statuscode, unter dem du deine normale Seite plus Zusatzinfo korrekterweise auslieferst, 200 OK.

MfG ChrisB

[levu]

Wie wäre es mit 423 Locked? [http://tools.ietf.org/html/rfc4918#section-11.3]

Und ansonsten ein Moved Temporary oder ein 503 mit Retry-After Header.

[Gunther]

Hallo!

Welches wäre der richtige http Status Code
für eine URL, die gültig ist,
die aber zwischenzeitlich nicht bedient wird
(zum Beispiel, weil die Seite wegen Abwesenheit der Admins nicht verfügbar ist).

Was bitte verstehst du unter "zwischenzeitlich nicht bedient wird"
im Hinblick auf

Mit dem Statuscode sollte auch die normale Seite, allerdings verändert im Content, ausgeliefert werden.

???
Imho haben HTTP Status Codes damit nichts zu tun. Du willst sie für etwas verwenden, wofür sie nicht gedacht sind. Ergo kann es keinen "richtigen" Status Code für dein Anliegen geben.

Zum Beispiel, um eben diese Nachricht mitzuteilen.

Mal ehrlich - wie sieht denn so ein Szenario aus, wo sein Vorhaben sinnvoll ist?

Bots sollten diese Seite in diesem Zustand nicht indexieren.

Wieder andere Baustelle (die gemeinhin nicht/ nie 100%ig realisiert werden kann).

Gruß Gunther

[Beat]

Nachdem ich eure Fragen und Vorschläge so gelesen habe, vielleicht mal ein konkretes Beispiel.

Angenommen man hat ein Gästebuch, das relativ offen ist.
In Abwesenheit des Admin soll dieses Gästebuch nicht beschreibbar sein (Aufsichtspflicht).
Der Inhalt des Gästebuchs wird durch eine Feriennotiz verändert.
Aber als solches ist es immer noch der übliche Content, fällt also in die 200er Rubrik.
Aber ich möchte nicht, dass Bots das Gästebuch mit dieser Notiz indexieren.

Ok. Die Lösung lautet halt: Deaktiviere alle Zuhänge zu Schreibaktionen und entferne die Notiz, sofern du einen Bot detektierst.

Das lässt sich also, wie von Chris bemerkt, mit 200 beantworten.

503 kann keine Lösung sein, weil Content dabei nicht vorgesehen ist.
302 kann für Bots eine Lösung sein, aber eine vollkommen unnötige. Was soll den das Ziel der Umleitung enthalten?

mfg Beat

[Gunther]

Hi!

... vielleicht mal ein konkretes Beispiel.

Angenommen man hat ein Gästebuch, das relativ offen ist.
In Abwesenheit des Admin soll dieses Gästebuch nicht beschreibbar sein (Aufsichtspflicht).
Der Inhalt des Gästebuchs wird durch eine Feriennotiz verändert.
Aber als solches ist es immer noch der übliche Content, fällt also in die 200er Rubrik.
Aber ich möchte nicht, dass Bots das Gästebuch mit dieser Notiz indexieren.

Ok. Die Lösung lautet halt: Deaktiviere alle Zuhänge zu Schreibaktionen und entferne die Notiz, sofern du einen Bot detektierst.

Zu dem genannten Beispiel fallen mir spontan folgende Möglichkeiten ein:
1.) Wenn du nur einem User quasi eine Nachricht zukommen lassen willst (bspw. "Bis ihr Kommentar freigeschaltet werden kann dauert es bis zum xx.xx.xxxx - ich bitte um Verständnis."), dann setze für die Seite aktiviertes JS voraus und blende die Mitteilung per JS ein.
HTTP Status: 200
Bot Problem sollte damit auch gelöst sein.

2.) Leite solange per Status 307 Temporary Redirect auf eine andere Resource um und verbiete diese den Bots per robots.txt! Oder detektiere Bots und liefere ihnen ganz normal per 200er die normale Seite. Welcher Bot nimmt schon Einträge in einem Gästebuch vor? Gegen die bösen Buben hast du ja sicherlich schon andere geeignete Maßnahmen getroffen und wenn sowieso eine Freischaltung der Beiträge erforderlich ist ...!

Gruß Gunther

[Tim Tepaße]

503 kann keine Lösung sein, weil Content dabei nicht vorgesehen ist.

10.5 Server Error 5xx
  [..
  Except when responding to a HEAD request, the server SHOULD include an entity
  containing an explanation of the error situation, and whether it is a temporary
  or permanent condition. User agents SHOULD display any included entity to the
  user. These response codes are applicable to any request method.

(“entity” ist der Körper der HTTP-Response in HTTP-Lingo.)

[ChrisB]

Hi,

503 kann keine Lösung sein, weil Content dabei nicht vorgesehen ist.

10.5 Server Error 5xx
  [..
  Except when responding to a HEAD request, the server SHOULD include an entity
  containing an explanation of the error situation, and whether it is a temporary
  or permanent condition. User agents SHOULD display any included entity to the
  user. These response codes are applicable to any request method.

Trotzdem halte ich 503 hier für unpassend.

Der Service „Anzeige der bisherigen Gästebucheinträge” ist absolut nicht temporary unavailable, sondern den will er ja weiterhin anbieten.

Lediglich das Anlegen neuer Einträge soll vorübergehend nicht möglich sein - also käme 503 höchstens als Antwort auf den POST-Request, mit dem Formulardaten an den Server geschickt werden, in Frage.

Also ist auch das Eintrage-Formular zu deaktivieren bzw. gar nicht erst anzuzeigen - denn den Nutzer das erst ausfüllen zu lassen, nur um dann anschliessend „Nein danke, jetzt nicht” zu sagen, wäre ganz schlecht.

Ich würde auch den Weg vorziehen, Einträge auch während der fraglichen Periode zu erlauben, und dem Nutzer dann eine Nachricht anzuzeigen, dass eine Kontrolle derzeit nicht möglich ist, und daher die Freischaltung des Eintrags zur Anzeige auf der Seite noch dauern wird.

Ob der Nutzer, der jetzt gerne einen Eintrag hinterlassen möchte, extra dafür zum Zeitpunkt X noch mal wieder kommt, dürfte nämlich auch fraglich sein.

MfG ChrisB

[Texter mit x]

Trotzdem halte ich 503 hier für unpassend.

Der Service „Anzeige der bisherigen Gästebucheinträge” ist absolut nicht temporary unavailable, sondern den will er ja weiterhin anbieten.

Nein, will er nicht. Er will temporär und im Sinne einer Fehlerseite etwas anderes ausgeben, was die bisherigen Gästebucheinträge enthält.

[ChrisB]

Hi,

Der Service „Anzeige der bisherigen Gästebucheinträge” ist absolut nicht temporary unavailable, sondern den will er ja weiterhin anbieten.

Nein, will er nicht. Er will temporär und im Sinne einer Fehlerseite etwas anderes ausgeben, was die bisherigen Gästebucheinträge enthält.

Diese Differenzierung halte ich für unsinnig.

Er will die Gästebucheinträge nach wie vor ausgeben.
Er will keinen Fehler melden, sondern die (zusätzliche) Information über die temporäre Nichtverfügbarkeit der Möglichkeit, neue Einträge anzulegen.

MfG ChrisB

[Beat]

Er will die Gästebucheinträge nach wie vor ausgeben.

ja

Er will keinen Fehler melden, sondern die (zusätzliche) Information über die temporäre Nichtverfügbarkeit der Möglichkeit, neue Einträge anzulegen.

Oder welche Information auch immer...

Das ist eben der Punkt. Die Seite enthält Zusatzinformation, die nicht indexiert werden soll. Jetzt tilge ich entweder für Bots diese Info, oder ich übergebe den Bots eben doch einen Statuscode, welcher die Nicht-Indexierung zur Folge hat.

Ich könnte auch anders fragen:
Gibt es in HTTP eine Möglichkeit, dem Client mitzuteilen, dass der Content nicht kanonisch ist, relativ zu einem kanonischen Inhalt.

Eine statische Seite liefert immer kanonischen Inhalt.
Eine Gästebuchabfrage bildet zwar Varianz, aber doch einen kanonischen Auszug.
Eine Seite, in der ein Fehler geschah, so dass der Content nicht vollständig dargestellt werden kann (wobei noch Fehlermessages enthalten sind), stellt nicht kanonischen Inhalt bezüglich der URI dar.
Das Script arbeitet fehlerfrei. Der Servervorgang ist fehlerfrei, aber der Inhalt wird als "ungültig" deklariert.
Dies sollte aber keine Versuche zur Folge haben, den Inhalt automatisch neu zu verlangen. Es sollte eher bewirken, dass der Client den Response nicht als einen repräsentativen Inhalt behandelt.

mfg Beat

[Texter mit x]

Das ist eben der Punkt. Die Seite enthält Zusatzinformation, die nicht indexiert werden soll. Jetzt tilge ich entweder für Bots diese Info...

Was zumindest theoretisch Cloaking und damit grundsätzlich gefährlich ist.

[Beat]

Das ist eben der Punkt. Die Seite enthält Zusatzinformation, die nicht indexiert werden soll. Jetzt tilge ich entweder für Bots diese Info...

Was zumindest theoretisch Cloaking und damit grundsätzlich gefährlich ist.

Blödsinn. Da müsstest du ja auch Javascript verbieten.
Abgesehen: wegtun kannst du immer. Nur hinzutun sollst du nicht für Bots.

mfg Beat

[Texter mit x]

Das ist eben der Punkt. Die Seite enthält Zusatzinformation, die nicht indexiert werden soll. Jetzt tilge ich entweder für Bots diese Info...

Was zumindest theoretisch Cloaking und damit grundsätzlich gefährlich ist.

Blödsinn.

Wie kann es denn kein Cloaking sein?

Zwischen Theorie und Praxis ist ein Unterschied und ich sage auch nicht den sicheren Absturz voraus. Kann gut sein, daß, falls es bemerkt wird, so was nicht automatisch negative Folgen hat, sondern jemand nachschaut ob das legitim ist (und es als legitim befindet, oder aber, und vielleicht fälschlich, als illegitim). Kann gut sein, daß bei so geringen Unterschieden auch nichts anschlägt, wer weiß das schon, theoretisch ist es aber Cloaking.

"Grundsätzlich" gefährlich war subjektiv vielleicht übertrieben aber Cloaking kann "böse" sein, somit besteht die Gefahr, daß Cloaking als "böse" gewertet wird.

Da müsstest du ja auch Javascript verbieten.

Nur weil die meisten bots das ihnen vorgesetzte Javascript nicht ausführen oder wie? Abwegig.

Abgesehen: wegtun kannst du immer. Nur hinzutun sollst du nicht für Bots.

Heißt Cloaking nicht "das unsichtbar Machen"? Da es Leute gibt, die in böser Absicht schon weiter gedacht haben als Du, oder zumindest, weil Suchmaschinenbetreiber bestimmt davon ausgehen, daß es so ist, ist auch das ein Trugschluß. Man kann durch Weglassen und Hinzufügen manipulieren.

[Sven Rautenberg]

Moin!

Das ist eben der Punkt. Die Seite enthält Zusatzinformation, die nicht indexiert werden soll. Jetzt tilge ich entweder für Bots diese Info, oder ich übergebe den Bots eben doch einen Statuscode, welcher die Nicht-Indexierung zur Folge hat.

Wenn deine URL nicht indiziert werden kann, fliegt sie über kurz oder lang aus dem Index. Was dann sicher verhindert, dass die Seite als Grundlage für Suchergebnisse dient. Das kann aber nicht gewünscht sein, denn dann könnte man sich das Indizieren des Gästebuchs gleich komplett schenken (robots.txt) und braucht sich dann keinen Kopf mehr um den HTTP-Statuscode zu machen.

Insofern ist Status 404 sicherlich am schädlichsten: Nicht nur wird mitgeteilt, dass die angeforderte URL nicht zu indizieren ist, es wird ebenso mitgeteilt, dass sie aufgrund von clientseitigen Gründen nicht verfügbar ist (Statusgruppe 4xx), und dass das Wiederholen des Requests keine Verbesserung der Lage mit sich bringt. Ein Suchspider wird das mit Sicherheit mit Elimination der URL (auch der vorher indizierten Seite) aus dem Index bewerten.

Aber auch ein 5xx-Statuscode dürfte je nach Zeitraum, in dem er immer wieder auftritt, einen Einfluss auf den Index der Suchmaschinen haben. Schließlich wird eine Suchmaschine nur Suchergebnisse auf Seiten bringen wollen, die existieren und erfolgreich abgerufen werden können.

Insofern verbieten sich eigentlich alle Spielereien am Statuscode, die über die Darstellung von "Fehler" das Indizieren des zusätzlichen Texthinweises verhindern wollen.

Es gibt zahlreiche Methoden, eine Indizierung zu verhindern:

• Einfügen des Textes per Javascript.
• Robots.txt
• Meta-Tag "robots"

Es gibt aber keine HTTP-Status, der besagt "behalte die alte Seite im Index, und indiziere nur die jetzt sichtbaren Veränderungen nicht".

- Sven Rautenberg

[Texter mit x]

Der Service „Anzeige der bisherigen Gästebucheinträge” ist absolut nicht temporary unavailable, sondern den will er ja weiterhin anbieten.

Nein, will er nicht. Er will temporär und im Sinne einer Fehlerseite etwas anderes ausgeben, was die bisherigen Gästebucheinträge enthält.

Diese Differenzierung halte ich für unsinnig.

Diese Differenzierung halte ich, da es sich um ein Beispiel handelt, für unerläßlich und darüber habe ich vor meiner Antwort auch nicht zu knapp nachgedacht.

[Tim Tepaße]

Aber ich möchte nicht, dass Bots das Gästebuch mit dieser Notiz indexieren.

Yahoo hat vor längerer Zeit einen Geniestreich in der Hinsicht gehabt: Bereiche der Webseite mit der CSS-Klasse "robots-nocontent" werden nicht indiziert. Leider hatte Google zumindest 2008 kein Interesse, das zu unterstützen.

[Beat]

Yahoo hat vor längerer Zeit einen Geniestreich in der Hinsicht gehabt: Bereiche der Webseite mit der CSS-Klasse "robots-nocontent" werden nicht indiziert. Leider hatte Google zumindest 2008 kein Interesse, das zu unterstützen.

Hi Tim
Ich habe es irgendwann aufgegeben, auf proprietären Mutwillen zu setzen.
Ich habe Seit BdE-Online eine sehr einfache Policy:
Nimm an, dass ernstzunehmende Index-Bots als solche zu erkennen sind.
Der Aufwand, deren merkmale zu registrieren, ist bei den grossen drei sehr klein.
Nebst den Usertypen Admin, Submadmin, Member und Guest führe einen Typ Robot.
Blende alle Teile aus, die Robots nicht indexieren sollen.
Pflege statt dessen ein Set von permanenten Bookmarklinks ohne Query-Strings.

@all

Meine Frage nach dem Bin-Auf-Hawai-Statuscode ist nicht eine dringliche im Sinne eines "ich muss jetzt dringend etwas machen". Aber es interessiert mich konzeptionell für zukünftige Implementierungen.

Da sind verschiedene Ansätze mit bestehenden Statuscodes:

503
pro:  Erlaubt oder empfiehlt Message-Body (Danke für die Berichtigung)
      Bots indexieren diesen Body nicht, denn es ist eine Error-Page.
cons: Er ist in der Rubrik Server-Error.
      Das muss ich vielleicht nicht so heiss essen.
      Die Tatsache eines Retry-after bekräftigt
      ein vorgesehenes Verhalten des Servers.
quest:Wie reagieren Browser auf solchen Content?
      Stichworte: Bookmark, History, Re-Request?
      Retry-After findet hier wie Anwendung?

404 (von Texter vorgeschlagen)
pro:  Message Body erlaubt
      Bots indexieren nicht,
      ziehen aber auch keine negativen Schlüsse bezüglich späterer Versuche.
      Meine langjährige Erfahrung mit 404.
cons: Browser ziehen zwar keine negativen Schlüsse (anders als bei 410)
      bezüglich Re-Requests
      Bookmark: Ja ich kann eine 404 Seite bookmarken,
      denn ich bookmarke die Url. Stimmt das immer?
      Consistenz: Content in einer 404 Seite 90% identisch zur normalen Seite?

200 (Chris)
pro:  Für Clients optimal.
cons: Bots: Erfordert Veränderungen im Content.
      (Wiederherstellung des kanonischen Index-Contents)

302 oder 307
pro:  Bots indexieren die ursprüngliche Url nicht.
cons: Unnötiger zusätzlicher Request.
      Das Umleitungsziel muss auf einer alternativen URL ausgeliefert werden.
Ich will diesen Vorschlag schon mal streichen, weil er nur das Problem verlagert.

WebDAV Methode? Unterirdisch.

Mein Vorläufiger Entscheid.

Unter der Voraussetzung, dass der Server auf Bots alternativ reagiert
für Bots:    503 (kein verboser Content-Body notwendig)
             ein Retry-After header kann mitgesendet werden.
für Clients: 200.

mfg Beat

[Texter mit x]

Welches wäre der richtige http Status Code
für eine URL, die gültig ist,
die aber zwischenzeitlich nicht bedient wird
(zum Beispiel, weil die Seite wegen Abwesenheit der Admins nicht verfügbar ist).

Mit dem Statuscode sollte auch die normale Seite, allerdings verändert im Content, ausgeliefert werden. Zum Beispiel, um eben diese Nachricht mitzuteilen.
Bots sollten diese Seite in diesem Zustand nicht indexieren.

Warum nicht 404?

"The server has not found anything matching the Request-URI. No indication is given of whether the condition is temporary or permanent. ... This status code is commonly used when the server does not wish to reveal exactly why the request has been refused, or when no other response is applicable.

Quelle: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html