Bug - Fixed Mirror logging needs to write entity encoded characters

I

Irrat

Member
I actually anticipate that I'll be sorting this problem out myself at a later point, though anyone is welcome to jump ahead and fix this.

The issue is as following

* Mirror logging in mafia is written by writing gCLI to a file, the output is written as html
* The html tags such as <font> <br> and the like are included in the resulting text. And the non-html unsafe characters should be entity encoded.
* However, the following was not encoded Preference _bastilleLastBattleResults changed from to MA<MD,CA<CD,PA>PD<br>
* Mirror logging doesn't seem to actually entity encode the characters as you would expect, which is normally a non-issue if people are reading it as a text file.
* Firefox struggles to load the html due to the invalid tags apparently declared

Two trains of thoughts come from this. The first is keeping it human readable, because Preference _bastilleLastBattleResults changed from to MD&#x3E;MA,CD&#x3E;CA,PD&#x3E;PA<br> isn't really.
The second is that the text is written as if its html, with tags included. So we should make sure its valid html.

I'm of the latter opinion. Especially if it makes it corrupt html which forces everyone to read it as .txt
Chrome, I think it didn't struggle as much on the page. But that's not a very good argument. "Chrome handles corrupt text without slowing down, so we don't need to fix" and all :P
 
My recollection is that my fingerprints are all over this one. At the time the task was to write EXACTLY the same thing to the mirror file and the gCLI. That meant HTML and everything else before it was rendered in the gCLI, ill formed or not. So my solution to this would be to force the html written to the gCLI to be "correct". Once it is correct then the issue with the mirror file should go away. Given all the ways in which KoL and KoLmafia can be used to generate HTML that is not universally renderable I can't get too excited about this. Just try do a browser Save As on a page in the relay browser to see what I mean.

Since your examples seem to be with specific preferences perhaps an alternate solution is to make sure the preferences are handled in an acceptable manner. While I would insist that preferences as stored in the file must be human readable and editable in a plain vanilla text editor I am open to the possibility that "MD&#x3E;MA,CD&#x3E;CA,PD&#x3E;PA<br>" could be considered human readable. While I accept that changing how a preference is stored has consequences I also have to ask whether there is a better delimiter or format that would eliminate the problem.
 
a) does <![CDATA[MA<MD,CA<CD,PA>PD]]> work?
2) is that human readable enough?
iii) is that something that can be usefully used (so that you would only use it to encapsulate values that need it, and not every single line, especially not lines where html *should* be mirrored as-is)?
 
Small update is that this is a little more complicated than I thought.

For starters, we don't differentiate between a html message and a plain text message.
We pipe valid html and invalid html and plain text to the same end functions.
And we don't expect to ever know if this is meant to be html or plain text.

So it's more accurate to say a proper fix would be to explicitly make any logging say if its plain text, or html we're feeding in. If <font> is a tag or we want to explictly show the text <font>

Or to rephrase again, that better behavior would be to change the request logging printing into two seperate functions.

RequestLogger.printHtml("text") and RequestLogger.printText("text")
 
I still suggest that an acceptable, but less intrusive fix would be to identify that "raw data" that generates invalid HTML and fix the raw data as it is stored or when it is logged. Right now I this seems like a lot of work for exactly one preference.
 
You must log in or register to reply here.
Back
Top