User tests: Successful: Unsuccessful:
The problem is that the current download system tries to read the filename from the Content-Disposition expecting that filename is quoted but that's not required. So in some sites (in this example from Github) the update fails.
This is the expected header by the system:
[Content-Disposition] => attachment; filename="plg_sys_mootable-1.1.1.zip"
This is the returned header from some sites:
[Content-Disposition] => attachment; filename=plg_sys_mootable-1.1.1.zip
As you can see the filename comes without the double quotes. I replaced the file name detection to work with both systems because now it's based on the equal sign.
I provided a demo plugin to test the issue.
(see the 3.x tracker here:
http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=33344
to get the demo plugin)
Please attribute this to @phproberto when merging as it's all his code from 3.x
Status | Pending | ⇒ | New |
Labels |
Added:
?
?
|
Status | New | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2014-08-10 19:40:50 |
Title |
|
Awesome :) Thanks!
This new implementation introduced a new bug.
The problem comes when you have a [Content-Disposition] that has additional fields after the filename like
[Content-Disposition] => attachment; filename="plg_sys_mootable-1.1.1.zip";modification-date="xxxx";size="xxx"
In this case, the filename that you get is:
plg_sys_mootable-1.1.1.zip";modification-date="xxxx";size="xxx
that is wrong.
Our proposal is to split the value on ";" and after remove the quotes (")
$flds = explode( ';', $parts[1]);
$target = trim( $flds[0], '"');
Merged into
2.5.-dev
.Also included the fix from #4025.