HTTP_ACCEPT
Een vraagje... maken jullie wel eens gebruik van $_SERVER['HTTP_ACCEPT']?
In mijn browser levert dit "text/html, application/xhtml+xml, */*" op, maar wat moet ik daar mee? Heb je dit ergens voor nodig?
Maar heb ik vooral voor testdoeleinden gedaan.
Bijvoorbeeld een webservice (api) kan data terugleveren in een formaat naar keuze.
Met HTTP_ACCEPT zegt de client (browser bij de test, maar kan ook php via curl zijn uiteraard) dat hij data begrijpt in html, json en xml met een voorkeur in die volgorde.
Laten we zeggen dan de api een array met namen terug wil geven.
html kan de api niet aan. Json wel, dus komt de data terug via
Komt een andere client later met de melding dat hij xml wil hebben:
Zou ook kunnen met een tekst in pdf of Word
of met een plaatje als jpg of gif etc.
Kortom: je geeft de client de mogelijkheid om data in een gewenst formaat op te vragen.
Toevoeging op 17/04/2014 10:54:41:
en ja: dat kun je ook in de url verpakken, maar net zo als je de GET/POST/PUT headers kunt gebruiken om aan te geven wat je wilt doen, en de server met http-headers status en foutmeldingen (404 not found, 400 bad request) kan geven,
zo kun je ook de accept gebruiken.
Wat ik bedoel is... als ik plaatjes op mijn site heb staan in jpg formaat, dan ga ik in de praktijk niet overal nog eens een gif van maken, voor het geval een browser geen jpg accepteert. Of, ik ga niet alle PDF's ook in Word aanbieden omdat sommige browsers geen pdf aankunnen enz.
Ik begrijp dat het voor een webapi nuttig kan zijn, maar is het bij "normaal" internetgebruik ook van toepassing?
application/x-ms-application, image/jpeg, application/xaml+xml, image/gif, image/pjpeg, application/x-ms-xbap, application/x-shockwave-flash, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */*
In de praktijk levert dat weinig of niets op: lang niet alle browsers die het MIME-type application/x-shockwave-flash ondersteunen verzenden ook de Accept-header application/x-shockwave-flash. Bovendien accepteren vrijwel alle browsers */*, dus alles. En als een browser toch alles accepteert, verliest de header zijn praktisch nut.
Als jouw praktijk bouwen van publieke websites is, dan zul je dat niet veel nodig hebben.
Bouw je api's, webservices etc dan is het dagelijkse kost.
En in jouw voorbeeldje ziet de "ontvangende partij" dus aan de header wat voor informatie er binnenkomt?
Maar hetzelfde effect zou je dus ook kunnen bereiken door de ontvangende partij specifiek om bijv. XML te laten vragen door dat als een parameter mee te geven in de URL? www.somesite.com/grabcontent?type=xml
Begrijp ik het zo goed?
Browsers zeggen altijd "ik heb het liefst HTML.", misschien gevolgd door "Als je dat niet voor me hebt, doe dan maar XHTML.", en daarna eigenlijk altijd "Als je dat niet hebt, kies jij dan maar".
De accept header wordt altijd verstuurt, met javascript kan je een AJAX request sturen waarvan je dan zelf de waarde voor de accept header mee kan geven. Maar als je op drie verschillende pagina's naar http://example.com/magic linkt en de ene keer xml, de andere keer json en nog een andere keer excel verwacht terug te krijgen, dan doe je iets goed fout.
Elke browser heeft, voor zover ik weet, */* in zijn Accept header staan, wat betekend dat als je iets maakt voor browsers je alles terug kan geven wat je wilt en de Accept header niet hoeft te parsen om zeker te weten dat de client (browser) ZEGT ermee overweg te kunnen.
Hoe besluit een browser naar blabla?format=xml te gaan? Hoogst waarschijnlijk heeft de server die locatie aangeleverd in de body van een andere request. Wat dus betekend dat blabla?format=xml oorsprokelijk bij de server vandaan komt, terwijl de Accept header die de client verstuur ALTIJD bij de client vandaan komt.
Gewijzigd op 17/04/2014 11:51:28 door Dos Moonen
Ivo P op 17/04/2014 11:20:01:
hangt van je praktijk af :-)
+1 :-)
Ozzie PHP op 17/04/2014 11:18:25:
Allright, thanks Ward. Dus wat jij eigenlijk zegt, is dat je deze variabele in de prakijk niet nodig hebt? Of begrijp ik je verkeerd?
Als de meeste browsers met */* melden dat ze alles accepteren, valt er verder weinig te onderhandelen. De header zegt dan niets anders meer dan: stuur maar op wat je hebt.
Technisch heeft de HTTP-header zeker bestaansrecht, maar als browser-bouwers massaal */* gebruiken, blijft er van content negotiation bitter weinig over. Ik vind dat eigenlijk een foute implementatie van HTTP1/1, maar bij Google, Microsoft, Apple & Co werken kennelijk slimmere programmeurs.
Voor API's kun je inderdaad wel een uitzondering maken, goed punt van Ivo. Maar zelfs daarbij zie je dat in de praktijk vaak een andere oplossing wordt verkozen: XML aanbieden via een andere URL dan JSON bijvoorbeeld.
Aangezien je een framework bouwt, zou ik de header dus niet resoluut naar de prullenbak dirigeren, maar er zeker ook geen hoofdcomponent van maken voor alle HTTP-verkeer.
Het lijkt me inderdaad handiger om, mocht dat ooit nodig zijn, gericht content aan te bieden:
www.site.com/content?type=xml
www.site.com/content?type=json
enz.
En voor andere vormen van content, denk bijv. aan flash, maar gewoon er vanuit gaan dat dat wordt ondersteund?
Ben ik met je eens... als het niet hoeft dan liever niet.
Maar goed... lang verhaal kort... die HTTP_ACCEPT heb ik dus voor normaal websitegebruik niet nodig? Gewoon aanbieden wat je hebt, en het gros van de browsers zal er mee overweg kunnen, en een enkele browser een enkele keer misschien niet. Vat ik het zo op de juiste manier samen?
PS. gebruik aub www.example.com als dummy links, site.com is een bestaande site. "You may use this domain in examples without prior coordination or asking for permission." - example.com.
site.com vind het mogelijk niet leuk dat je search engines naar niet bestaande pagina's stuurt.
Gewijzigd op 17/04/2014 13:47:05 door Dos Moonen
Wat bedoel je precies met je vraag? Die query string kan netter, is dat wat je bedoelt?
Ik kan ook dit doen: www.example.com/content/xml
Of bedoel je iets anders en begrijp ik je verkeerd?
>> site.com vind het mogelijk niet leuk dat je search engines naar niet bestaande pagina's stuurt.
Tja, beetje het risico van zo'n naam :)
Ozzie PHP op 17/04/2014 13:49:16:
Tja, beetje het risico van zo'n naam :)
Wat aardig van je.
Ik bedoelde, wat voor versie ga je opleveren als iemand naar example.com/content?geen-format-om-te-bepalen-wat-voor-content-terug-gestuurt-moet-worden gaat?
Geef je de HTML versie? de XML versie? de Json versie? een 404 status code met HTML content?
URL staat voor Uniform Resource Locator. Een resource heeft maar één soort content-type. Als jij op basis van de query string de content-type gaat veranderd is dat dus niet heel net. Als jij op basis van de query string bepaalde content weg laat filteren gebruik je de query string precies waarvoor het bedoeld is.
example.com/content hoort altijd de zelfde soort content te leveren, niet de ene keer XML en de andere keer HTML. Dat hoor je niet op te lossen met de query string aangezien entensions beter geschikt zijn: Je verwijst naar een andere resource, met grotendeels de zelfde naam.
example.com/content/xml zou ook kunnen, maar een OS zou het niet herkennen als een XML bestand. Wat mogelijk irritaties op kan leveren.
Gewijzigd op 17/04/2014 14:05:51 door Dos Moonen
Wat bedoel je hiermee? Waarom zou een OS /content wel herkennen en /content/xml niet?
Het is een erg klein puntje. Browsers zijn slim genoeg om zelf een extensie toe te voegen wanneer ze iets opslaan.
Maar Command Line tools als wget en curl doen zoiets niet voor zover ik weet. Dus dan zou je een bestand genaamd "xml" in de map "content" en zal je OS het proberen te openen met het programma dat is ingesteld om bestanden zonder extensie te openen.
Ik ben nu aardig "Technisch gezien zou ... netter zijn" bezig.
www.example.com/content/xml/foo.xml
Dat bedoel je waarschijnlijk.