Header-virussen omzeilen contentscanners

Mwah, het HTTP protocol gebruikt bijvoorbeeld \r\n als afsluiting van een header. Terwijl de afsluiting van een regel op Unix/Linux slechts \n is. Op MS Windows is hij weer \r\n. Dat zijn dus best wel verwarrende dingen . (als je de term newline gebruikt zijn er uiteraard geen verschillen. De term newline is helaas overloaded in dit geval ).

Toevallig had ik zelf een keer een implementatie gemaakt die met \n werkte. Deze moest tegen .NET aanpraten. In beta 1 werkte dit nog goed, in beta 2 ontdekte ik de vergissing pas.

Verder zie ik het probleem van de gebufferde IO niet zo. Dit is typisch weer een component probleem. Als je een goede XML parser gebruikt met bijvoorbeeld een SAX interface kan deze volgens mij nog steeds gebruik maken van gebufferde IO. Deze parser zal toch al deze routines moeten hebben om op een efficiente manier met het parsen van XML om te gaan. Pak maar eens een SAX parser erbij: als een document nog niet helemaal binnen is, heb je toch al een groot deel van het document wat al wel binnen is, binnen gekregen via je ContentHandler.

Het grote verschil tussen een parser die een HTTP message moet parsen en een parser die een XML message moet parsen is dat de eerste kennis heeft van de toepassing van de syntax. Je kant deze dus in feite alleen gebruiken voor een HTTP protocol (of iets wat daar sterk op lijkt). Een XML parser kan je voor ontzettend veel doeleinden gebruiken en daarom kan er extra veel aandacht besteed worden aan dat component. Ook kan je standaard validatie gebruiken tegen bijvoorbeeld een DTD of een XML Schema.

Uiteraard kan die nog steeds bugs bevatten, maar omdat het een generieke implementatie is, is het de moeite waard om te investeren in de kwaliteit van de implementatie. Vanwege de generieke toepassing zullen fouten waarschijnlijk ook sneller worden gevonden.