300 Multiple Choices: de code die u vrijwel nooit ziet

Waarvoor de code was bedoeld

HTTP ondersteunt contentonderhandeling: dezelfde URL kan meerdere representaties hebben die verschillen in formaat, taal of encodering. Normaal gesproken beslist de server, aan de hand van de headers Accept, Accept-Language en Accept-Encoding van de client, en geeft hij de gekozen versie terug met een 200. Dat is server-gestuurde onderhandeling, en dat is hoe het web werkt.

300 Multiple Choices dekt de andere aanpak, agent-gestuurde onderhandeling. In plaats van te kiezen, antwoordt de server met een lijst van de beschikbare representaties en laat hij de client of de gebruiker kiezen. Het antwoord kan een Location-header bevatten die de voorkeursoptie van de server noemt, die een client vrij is te volgen.

Waarom u er vrijwel nooit een tegenkomt

De standaard heeft nooit een machineleesbaar formaat voor de lijst met keuzes gespecificeerd. Zonder afgesproken formaat is er niets voor een browser om te parseren, dus geen enkele mainstream browser implementeert een keuze-interface voor een 300. Browsers tonen de responsebody meestal gewoon als een normale pagina, of volgen de Location-header als die aanwezig is, waardoor de 300 zich gedraagt als een zwakke redirect. Applicatieframeworks en CDN's sturen hem niet in hun standaardconfiguratie, en server-gestuurde onderhandeling lost hetzelfde probleem onzichtbaar en beter op, dus niemand heeft reden om over te stappen.

Een 300 duikt nog wel op een paar plekken op:

• Apache's mod_negotiation met MultiViews ingeschakeld, wanneer meerdere bestanden overeenkomen met een verzoek zoals /logo en de module ze niet kan rangschikken. Het genereert een HTML-lijst van kandidaten.
• Met de hand geschreven API's die opzettelijk een JSON-lijst met alternatieve resource-URL's teruggeven, waarbij 300 als semantische hint wordt gebruikt in plaats van te verwachten dat een client hem native afhandelt.
• Testsuites en protocolconformiteitstools die elke gedefinieerde statuscode uitoefenen.

Waarom mensen op "300 status code" zoeken

De meeste zoekopdrachten naar "300 status code" gaan helemaal niet over een 300. Het getal is het begin van de redirect-familie, dus mensen die een redirect zagen in een browsertool, een log of een SEO-crawler en zich "een 3-honderd-zoiets" herinnerden, zoeken eerst 300 op. Wat ze meestal hebben, is:

• Een 301, een permanente redirect, gemeld door een SEO-crawler als onderdeel van een keten.
• Een 302, een tijdelijke redirect, de standaard die veel frameworks versturen.
• Een 304, wat helemaal geen redirect is maar een cachevalidatieantwoord.
• Een crawler-samenvatting die alles onder een kopje "3xx" groepeert, wat vervolgens wordt gelezen als "300".

Probeert u uit te vogelen welke redirect een URL teruggeeft, dan is de handleiding 301 versus 302 degene die u zoekt.

Hoe u controleert of u echt een 300 heeft

1. Vraag om de headers zonder een redirect te volgen en lees het exacte getal:

   curl -sI https://example.com/some-path | grep -Ei "^(HTTP|location|link|alternates)"

   Een echte 300 toont HTTP/1.1 300 Multiple Choices. Iets anders is een andere code en een andere handleiding.
2. Is het echt een 300 en was dat niet uw bedoeling, kijk dan eerst naar Apache. MultiViews uitschakelen voor die map, of het bestand een expliciete extensie in de URL geven, verwijdert de dubbelzinnigheid die de onderhandeling activeert.
3. Wilt u dat de server kiest, houd dan server-gestuurde onderhandeling aan: geef 200 terug met de geselecteerde representatie en een Vary-header die de headers noemt waarop u onderhandelde, zodat caches de varianten apart bewaren.
4. Wilt u clients ergens anders naartoe sturen, gebruik dan een echte redirect. Permanente verplaatsingen krijgen 301 of 308, tijdelijke krijgen 302 of 307. Gebruik geen 300 als redirect, want clients zijn niet verplicht die te volgen.
5. Los de dubbelzinnigheid bij de bron op. Een 300 betekent bijna altijd dat twee bestanden of twee routes om dezelfde URL concurreren, en de duurzame oplossing is de URL ondubbelzinnig te maken.

Een onverwachte 300 opsporen na een deployment

Een onverwachte 300 komt meestal binnen bij een serverupgrade of een configuratiewijziging, en niemand merkt het: de pagina kan er in een browser nog ongeveer goed uitzien terwijl crawlers en API-clients een antwoord krijgen dat ze niet kunnen gebruiken. Een externe controle die de exacte statuscode voor elke URL vastlegt, brengt de wijziging aan het licht bij de eerste run na de deployment. HostTracker monitort al sinds 2004 websites en voert controles uit vanaf 300+ controlepunten in 158 steden. Controleer wat een URL op dit moment teruggeeft met de HTTP-controletool, of lees de volledige handleiding de 3xx-redirectfamilie.