#foswiki 2016-10-13,Thu

↑back Search ←Prev date Next date→ Show only urls(Click on time to select a line by its url)

WhoWhatWhen
***ChanServ sets mode: +o gac410 [00:37]
....................................................... (idle for 4h30mn)
gac410 has left [05:07]
........... (idle for 54mn)
ChanServ sets mode: +o CDot [06:01]
...................................................... (idle for 4h29mn)
card.freenode.net sets mode: +o ChanServ [10:30]
........... (idle for 54mn)
ChanServ sets mode: +o Lynnwood [11:24]
................... (idle for 1h30mn)
ChanServ sets mode: +o CDot [12:54]
...... (idle for 28mn)
ChanServ sets mode: +o gac410 [13:22]
ChanServ sets mode: +o Lynnwood__ [13:27]
................................................................................. (idle for 6h43mn)
vrurggac410: Hi! Are you available? [20:10]
......... (idle for 43mn)
gac410hi vrurg ... I'm back [20:53]
vrurgI'm already debugging... Trying to locate where is file name is entity decoded when attachment is deleted. I thought it should be only url encoded when passed in as a query parameter. [20:56]
gac410I think the filenames are all encoded/decoded directly in the Store modules.
well.... decoded from utf8 to unicode on the way in from the query, and then re-encoded to the {store}{encoding} when accessed in the file system in store.
[20:57]
vrurgIncluding entiry encoding? I mean _ for underscore, etc...
entity...
[20:58]
gac410Er, no, no entity encoding in the store. ... I don't believe
Entity encoding is done at the query interface iirc. internally it's always unicode.
[20:59]
vrurgSure it's not there. Yet, try deleting an attachement with underscore and you'll get an error. [21:00]
gac410On master too? [21:00]
vrurgYeps.
I've just finished testing the master.
[21:00]
gac410gac410 goes to try. [21:00]
vrurgLine 99 in UI/Attachment.pm and below – url for Delete action is getting entity encoded. But it must not. [21:01]
gac410YIKES: Attachment move failed During move of attachment id_rsa.pub to . an error was found. [21:04]
vrurgIt's the latest commit to UI/Attachment.pm which broke it – 26791754ab456c02b4dc3ce79e0938a5db723ddb
Affected OO branch too after merge.
[21:04]
gac410yeah. something not right there. Let me look at the task a bit
okay, so the encoding is "correct" in principle, but clearly at the wrong place. We should entity encode only during output.
[21:05]
vrurgIt's in attachanother.tmpl. Delete action is initiated by a URL with file name in it. The file name gets entity encoded by Attach.pm and then url encoded with %ENCODE{}%. So, the Rename.pm gets it entity encoded but it doesn't expect it to be this way.
It looks to me like there must be either two different %FILENAME% macros – one for output, another for manipulations. Or url must be formed using %URLPARAMS%
unless I'm mistaken with the macro name.
[21:06]
gac410Ah...okay, so %FILENAME% is actually a template token, not a macro :( And it's used as output in a template, so encoding when expanding the template is correct.
I've got to look at the template some more though.
[21:10]
vrurgOk, I'll leave it to you. Have a performance problem with RegisterTests after my latest buch of changes... [21:12]
gac410Don't forget I merged in register test changes as well. [21:13]
vrurgOops. ;) Ok, I'll find what's wrong. Though my changes are more likely to cause the issue. [21:15]
gac410On encoding of filename, I think the original fix is bad, and that the encoding is required in the template. ie: [[%ATTACHURLPATH%/%ENCODE{%FILENAME%}%][%FILENAME%]]
should really be: [[%ATTACHURLPATH%/%ENCODE{%FILENAME%}%][%ENCODE{"%FILENAME%" type="safe"}%]]
the left side of the [[ ]] is URL encoded, and the right side of the link should be encoded as well.
I'll test that a bit.
[21:19]
vrurgLooks much better this way. [21:26]

↑back Search ←Prev date Next date→ Show only urls(Click on time to select a line by its url)