Scriptorama.nl

Van het weekend was ik aan het spelen met de Twitter API en liep, ondanks een caching constructie, op een gegeven moment toch tegen het rate limit aan; je mag vanwege de performance problemen eerder dit jaar momenteel max. 20 requests per uur naar de Twitter API doen.

De Twitter API geeft dit aan met een HTTP 400 response code. Ik kon dit alleen niet goed detecteren want fopen() retourneert alleen maar FALSE en ik wilde graag de daadwerkelijke HTTP response code hebben.

Het feit dat je PHP dan toch al behoorlijk wat jaartjes gebruikt houdt niet in dat PHP dan ook geen verrassingen meer voor je heeft. Sowieso aangezien er behoorlijk wat toegevoegd wordt aan PHP, maar ook omdat er soms gewoon rare, verstopte, dingen in PHP zitten. Het detecteren van de HTTP response headers bij een mislukt HTTP request is daar wat mij betreft een van.

Het probleem met fopen() en stream wrappers

Laten we er even wat code bij pakken. Hieronder volgt een manier om de REST API van Twitter aan te spreken. Je krijgt hiermee, mits je de juiste gegevens invult, een lijst van de mensen die jou volgen in JSON formaat:

Note: Je hebt misschien opgemerkt dat ik hier geen timeout handling implementeer en dat is met de Twitter API best wel belangrijk gezien Twitter's uptime record :P. Dit heb ik gedaan om de code kort en duidelijk te houden. Elders op Scriptorama kun je leren hoe je timeouts met PHP streams kunt afhandelen.

Je kunt in dit voorbeeld, als het HTTP request lukt, eventueel de HTTP request headers achterhalen met de functie stream_get_meta_data(). Maar op het moment dat het request niet lukt, doordat je bijvoorbeeld een niet bestaande actie aanroept (HTTP 404) of je hebt meer requests in een uur gedaan dan toegestaan (HTTP 400), dan zal fopen() FALSE terug geven.

Helaas kun je stream_get_meta_data() dan niet meer gebruiken omdat deze een valide stream resource verwacht en die hebben we niet gekregen van fopen().

Een oplossing is om fopen() niet meer te gebruiken en gebruik te maken van fsockopen() en het HTTP protocol zelf dan maar enigzins te implementeren. Dat geeft je directe toegang tot alle headers. Dat kan, maar daarmee gooi je een hoop functionaliteit (redirects, het combineren van andere stream wrappers) de deur uit. Niet een goed idee dus.

Het is (gelukkig) mogelijk om er achter te komen wat er nou precies gebeurd is. Het zit alleen een beetje verstopt.... and it ain't pretty....

De oplossing: $http_response_header

Wat PHP namelijk doet bij het gebruik van de HTTP stream-wrapper via bijv. fopen() is een variabele aanmaken genaamd $http_response_header. Dat lees je goed, PHP maakt in je huidige scope een nieuwe variabele aan. How's that for a WTF-factor?

Deze variabele, een array, bevat alle HTTP response headers als element:

Met een simpele regular expression kunnen we dus de HTTP response code uit het eerste element van $http_response_header halen:

Conclusie

De magische variabele $http_response_header kan je helpen bij het verwerken van HTTP requests die niet helemaal gaan zoals je misschien verwacht had.

Zoals je misschien gemerkt hebt vind ik het niet echt een knap systeem. Een variabele die ineens bestaat is een grote WTF-factor wat mij betreft. Zelf had ik eigenlijk verwacht dat dergelijke informatie verwerkt zou worden in bijvoorbeeld een stream context (voorbeeld van het gebruik van een stream context). Deze wordt momenteel alleen gebruikt om een stream te configureren, waarom ook niet gebruiken om informatie over het request in op te slaan? De naam context is er breed genoeg voor.