Fout in Pushmessage op T.net

[AW_Bos]

Zojuist kreeg ik een Pushmessage met daarin wat informatie en een activatie key voor de gratis opslagruimte.


Echter hier zie ik wat fouten in:
- Deze pushmessage wel ik op t.net zag, lijkt nl2br() te missen, aangezien alles achter elkaar staat, tot in tegenstelling met de PM die ik op GoT zie, waar de tekst wel voorzien is van enters.
- Wat is het practisch nut van de server-signature onderaan de pushmessage op t.net? Een pushmessage is per definitie geen server-fout waarbij je wel een server-signature zou moeten zien (zoals bij 404, 403 etc..)

[crisp]

AW_Bos schreef op woensdag 05 mei 2010 @ 17:09:
Zojuist kreeg ik een Pushmessage met daarin wat informatie en een activatie key voor de gratis opslagruimte.
[afbeelding]

Echter hier zie ik wat fouten in:
- Deze pushmessage wel ik op t.net zag, lijkt nl2br() te missen, aangezien alles achter elkaar staat, tot in tegenstelling met de PM die ik op GoT zie, waar de tekst wel voorzien is van enters.

Dit soort automatische pushmessages worden eigenlijk non-parsed weggeschreven en zonder parser-versie. Dit zorgt er binnen React voor dat bij de eerste opvraag de content alsnog geparsed wordt en voorzien van de juiste parser-versie ('on demand' dus zeg maar) - dat maakt het versturen van mass-pm/dm's behoorlijk efficienter.

Hier komt echter het nadeel van het weergeven van PM's op de frontpage om de hoek kijken; die doet itt React geen check of de content al geparsed was. Het is ook niet eenvoudig om vanuit de frontpage code de React parser aan te roepen, en de frontpage parser is feature-wise nog niet up-to-par met de React parser.

Dit is dus een hangende issue welke eigenlijk pas echt opgelost kan worden als we 1 enkele parser hebben voor zowel frontpage als forum. In de tussentijd heb ik iig een nl2br toegevoegd zodat je in deze gevallen toch wat meer formatting hebt

- Wat is het practisch nut van de server-signature onderaan de pushmessage op t.net? Een pushmessage is per definitie geen server-fout waarbij je wel een server-signature zou moeten zien (zoals bij 404, 403 etc..)

Er wordt middels de status header toch wel degelijk een afwijkende melding gedaan; je krijgt namelijk een 503 - Service Unavailable. De opmaak in de vorm van een soort van custom errorpage inclusief server signature is dus imo niet zo gek.