D9ping

Laatst had ik het probleem dat een website fouten gaf o.a. dat het doctype van de pagina misvormt was.
Ook mijn gedefineerde content security policy had opeens alles op de pagina geblokkeerd. Terwijl het echt wel leek dat de gedefinieerde content security policy het laden wel zou moeten toelaten. Ik had vrij snel het vermoeden dat het om een tekst encoding probleem ging. Echter ik had het bestand toch opgeslagen als unicode ‘UTF-8’ tekst encoding en dit was ook de encoding waarop webserver ingesteld staat. Hoe kan het dan misgaan?
Na wat sniffen met wireshark bleek er voor het eerste tekens in de bronweergave van de webbrowser nog een paar tekens extra te staan die niet weergegeven waren.
Wat was het probleem? Ik had de broncode bestanden van de website opgeslagen als UTF-8 met notepad++ en niet aangeven dat ik géén Byte order mark tekens wilde.
Hierdoor zijn er in het begin van het php document nog voor de <?php tekens nog een paar Byte order mark(afgekort: BOM) tekens opgeslagen. En deze tekens werden dus direct naar de cliënt verstuurd als hexidecimaal waardes: 0xEF,0xBB,0xBF.
Ook de server http headers zijn door het toevoegen van de BOM tekens al verzonden waardoor de content security policy header die in php gedefinieerd was laten niet meer gaat omdat de http headers al verzonden zijn doordat de pagina inhoud al is verzonden doordat de BOM tekens pagina inhoud zijn.
Het is dus verstandig BOM tekens te vermijden in broncode bestanden van je server side programmeer talen als je geen problemen wilt. Het W3C dat de web standaarden definieert heeft er ook al eens iets over geschreven.