REDIRECT_STATUS
Nu vraag ik me af... is dit de status die mijn server naar de browser stuurt? Dat kan toch niet? Stuurt de browser dan ook een status naar de server toe? En zo ja... waarom?
Toevoeging op 08/02/2013 00:21:26:
wat ik dus niet helemaal snap...
IK (de server) stuurt toch een status naar de browser? De browser stuurt toch geen status naar de server?
Waar komt die REDIRECT_STATUS in de $_SERVER array dan vandaan? Wat houdt het in?
Het lijkt er op alsof die variabele enkel een waarde krijgt wanneer je in een error page komt, doorgestuurd door .htaccess
Op dat moment zie ik wel waarom dit nuttig kan zijn.
Dus stel iemand bezoekt een pagina die niet bestaat, dan is de REDIRECT_STATUS van de server 404? Het is toch niet zo dat de browser van de bezoeker een status stuurt naar de server?
En daarbij zou het dus die variabele zetten.
Dus dit is puur server werking.
Dus stel de browser roept een pagina aan en die pagina is verboden, dan is de REDIRECT_STATUS 403. Begrijp ik het zo goed?
Het is niet de webbrowser die een onbestaande url laat redirecten naar 404.php
Dat doet de server; via .htaccess.
Het lijkt me dus dat, bij die redirect door de server, php een extra $_SERVER variabele activeert.
Iets wat handig kan zijn mocht je alle error pagina's loggen in de database.
Dan kan je bv. tellen hoeveel volk er op 404 komt ...
- SanThe - op 08/02/2013 13:30:08:
Kan je toch simpel even testen.
Zet een project op met iets van .htaccess
Log alles wat je op het scherm zet
Surf dan naar een onbestaande pagina (bv. index2.php) (de 404 valt gemakkelijk te testen)
Gewijzigd op 08/02/2013 14:11:18 door Kris Peeters
Maar dat is mijn mening, nvm me.
maar OT: het is wat al genoemd is, het geeft simpelweg de status van de pagina op het moment. Als je dan ook niet via .htaccess de pagina doorlinkt naar een errorpagina, dan is het ook gebruikelijk om hem handmatig bij te stellen ($_SERVER['REDIRECT_STATUS'] = 404;)
Jyy An op 08/02/2013 19:28:26:
Ik negatief? Ik zie jou hier voor het eerst op het forum en dan kom je met dit soort conclusies? Grappig. Wel eerst even research doen voortaan.Als je zelf geen moeite wilt doen om iets te leren vind ik het jammer dat je toch zo direct negzatief reageert op mensen hier die je proberen te helpen.
Lijkt me overigens niet de bedoeling dat je server variabelen gaat aanpassen maar dat terzijde.
Wanneer je surft, dan wordt het HTTP protocol gebruikt, een protocol dat overigens over een TCP verbinding gaat (wat overigens ook een protocol is). HTTPS is ook het HTTP protocol, maar met het verschil dat aan beide kanten (dus: de client en server) SSL wordt gebruikt.
Dit heeft als gevolg dat je browser een request doet (bv. GET). Deze request wordt naar een bepaald IP gerouteerd (daarvoor heb je dan weer het DNS en routeringsprotocollen nodig) en als je geluk hebt, zit er aan de andere kant een webserver. Deze webserver zal meestal een Apache webserer of een IIS server zijn. Deze weten dus wat het HTTP protocol inhoudt. Even kort uitgelegd, als jij een request doet (en laten we er even vanuit gaan dat er effectief een webserver online is), dan verwacht jouw browser een response. Die response krijg je terug in de vorm van header. In die header staat ook nog wat andere 'troep', bijvoorbeeld wanneer de pagina het laatste werd bewerkt (cache-doeleinden, op client-side niveau wel te verstaan). Deze header, die zit inbegrepen in de response, die door de webserver dus wordt gegenereerd.
PHP kan je ergens bekijken als een soort tussenlaag voor de webserver, bv. Apache. Apache krijgt een request, weet op een of andere manier dat het om een PHP script gaat, zegt tegen PHP `Doe je ding´ en krijgt terug wat hij wilt. Apache geeft eveneens wat informatie aan PHP, o.a. het IP van de surfer, en dus ook redirect status en dergelijke. Dat soort gegevens komt dan terecht in o.a. $_SESSION, $_SERVER en $_COOKIE variabelen.
Voor zover ik netwerken en de bijhorende protcollen heb begrepen ten minste ;-)
Met .htaccess (eigenlijk een configuratiebestand) of php.ini (op overkoepelend niveau) kun je een bepaalde status code doorsturen naar een ErrorDocument. Als de status code bijv. 404 (niet gevonden) is, dan stuur je het verzoek door naar een 404 ErrorDocument. Ik heb zelf .htaccess uitgeschakeld omdat het vertragend werkt. Ik regel alles via php.ini
De rest van je verhaal klopt ongeveer wel, behalve dat "dat soort gegevens" alleen in de $_SERVER array terecht komt en niet in de $_SESSION en $_COOKIE array. Die hebben niks met de server gegevens te maken.
Mocht er geen error page gemaakt zijn, zal Apache of zijn eigen error page tonen, of een 404 status code terugsturen naar de browser die er vervolgens wat leuks mee gaat doen.
Wouter J op 09/02/2013 01:10:13:
in dat geval zal hij een request doen naar die error page en dan zal hij dus een REDIRECT_STATUS header meegeven.
Dit gebeurt niet alleen als ie een pagina kan vinden. De REDIRECT_STATUS parameter wordt altijd gezet. Ook als de URL wel wordt gevonden. Dan is de status 200 (OK). Er is dus altijd een REDIRECT_STATUS.
Ozzie, degevens in de $_SESSION komen zeker en vast wél als gevolg van webserver-activiteiten. Informatie over een cookie (wat een noodzaak is voor een sessie) wordt door de browser en server uitgewisseld. En wie zorgt voor informatie over cookies, juist ja, het HTTP protocol behandelt dit. (Set-cookie langs server-kant naar client to, en vanuit client cookie naar de server toe). En hoe weet PHP dan informatie over cookie(s), juist ja, de webserver dient PHP hiervan op de hoogte te brengen :-)
Niet overtuigt? Wat dacht je van wanneer een cookie verstreken is (dus: de sessie is niet langer geldig). Enerzijds is de browser die aan de server moet zeggen welke cookies hij heeft, de webserver moet dan maar zien wat er mee gebeurd. Niet meer geldig --> PHP wakker maken en een HTTP-response sturen. In dat proces heb jij dus geen enkele regel code geplaatst om iets te doen wat mogelijk invloed zou kunnen hebben op $_SESSION.