Statuscode 300 Multiple Choices

Was bedeutet der Statuscode 300 Multiple Choices?

Mit dem HTTP-Status 300 Multiple Choices beantworten Server Anfragen, die auf unterschiedliche Art und Weise bedient werden können. Der Statuscode 300 informiert den anfragenden Client darüber, dass die Zielressource mehr als eine Repräsentation aufweist, jede mit ihrer eigenen, spezifischeren Kennung. Informationen über die Alternativen werden bereitgestellt, sodass der Benutzer (oder Benutzeragent) eine bevorzugte Repräsentation auswählen kann, indem er seine Anforderung an einen oder mehrere dieser Identifier umleitet. Mit anderen Worten, der Server wünscht, dass der Benutzeragent eine reaktive Verhandlung durchführt, um die am besten geeignete(n) Repräsentation(en) für seine Bedürfnisse auszuwählen. Dies wird durch den Statuscode 300 Multiple Choices übermittelt.

Serverseitiger Umgang mit dem Statuscode 300

Wenn der Server eine bevorzugte Wahl hat, sollte der Server ein Location Header-Feld erzeugen, das die URI-Referenz einer bevorzugten Auswahl enthält. Der Benutzeragent kann den Wert des Felds Location für die automatische Umleitung verwenden. Für andere Anforderungsmethoden als HEAD sollte der Server eine Nutzlast in der 300 Multiple Choices Antwort erzeugen, die eine Liste von Darstellungsmetadaten und URI-Referenzen enthält, aus denen der Benutzer oder Benutzeragent die bevorzugte Option wählen kann. Der Benutzeragent kann automatisch eine Auswahl aus dieser Liste treffen, wenn er den bereitgestellten Medientyp versteht. Ein spezifisches Format für die automatische Auswahl ist nicht durch diese Spezifikation definiert, da HTTP versucht, orthogonal zur Definition seiner Nutzdaten zu bleiben. In der Praxis wird die Darstellung in einem leicht zu parsenden Format bereitgestellt, von dem angenommen wird, dass es für den Benutzeragenten akzeptabel ist.

Eine 300 Multiple Choices Antwort kann standardmäßig zwischengespeichert werden, solange nicht anders durch die Methodendefinition oder die expliziten Cache-Steuerelemente angegeben. Der ursprüngliche Vorschlag für 300 Multiple Choices definierte das URI-Headerfeld noch als eine Liste alternativer Darstellungen, sodass es für 200-, 300- und 406-Antworten verwendbar gewesen wäre und als Antwort auf die HEAD-Methode übertragen werden könnte. Mangelnde Bereitstellung und fehlende Übereinstimmung über die Syntax führten jedoch dazu, dass sowohl URI als auch Alternates (ein nachfolgender Vorschlag) aus dieser Spezifikation entfernt wurden. Es ist möglich, die Liste mit einem Satz von Link Header-Feldern zu kommunizieren, die jeweils die Beziehung “alternate” haben, obwohl die Bereitstellung gewissermaßen ein Henne-Ei-Problem ist.

300 Multiple Choices – Der Client hat die Wahl

Die angeforderte Ressource entspricht irgendeiner einer Gruppe von Darstellungen, jede mit ihrer eigenen spezifischen Location. Client-gesteuerte Verhandlungsinformation wird bereitgestellt, sodass der Benutzer (oder Benutzeragent) eine bevorzugte Darstellung auswählen und diese Anfrage an diese Location umleiten kann. Sofern es sich nicht um eine HEAD-Anfrage handelte, sollte die Antwort eine Entität enthalten, die eine Liste von Ressourcenmerkmalen und Orten enthält, aus denen der Benutzer oder Benutzeragent die am besten geeignete wählen kann. Das Entitätsformat wird durch den Medientyp angegeben, der im Header-Feld Content-Type beschrieben ist. Abhängig von Format und den Fähigkeiten des Benutzeragenten kann die Auswahl der am besten geeigneten Wahl automatisch durchgeführt werden. Diese Spezifikation definiert jedoch keinen Standard für eine solche automatische Auswahl.

Falls der Server eine bevorzugte Repräsentationswahl hat, sollte er den spezifischen URI für diese Repräsentation in das Feld Location aufnehmen. Benutzeragenten können den Wert des Felds Location für die automatische Umleitung verwenden. Diese Antwort kann im Cache gespeichert werden, sofern nicht anders angegeben.