URL encode file names

[GoogleCodeExporter]

We use openwrt on the Arduino Yun 
http://arduino.cc/en/Main/ArduinoBoardYun?from=Products.ArduinoYUN

Arduino uses DreamHost as file storage. DreamHost fails when the file you 
request has a "+" in the name: it expects the url to be encoded (and thus the 
"+" should be a "%2B")

We patched opkg_dowload.c to replace "+" with "%2B"

The patch is available at
https://raw.githubusercontent.com/arduino/openwrt-yun/master/package/opkg/patche
s/090-urlencode-pluses.patch

It introduces a new function called 

file_name_url_encode

we call once with 

char *new_src = file_name_url_encode(src, '+', "%2B");

Please consider applying this patch.

Thank you

Federico

Original issue reported on code.google.com by federico...@gmail.com on 11 Jul 2014 at 8:32

[GoogleCodeExporter]

Please see the 'CONTRIBUTING' file in the latest opkg release for instructions 
on how to submit patches to opkg.

That said, this patch isn't really appropriate for merging anyway. It addresses 
only the specific escape '%2B' for '+'. For a patch to be merged it would have 
to be much more general. It would also have to be controlled by a config file 
option so that users can enable or disable it as needed.

I actually think the wget backend should do as little as possible as it is 
mainly used in cases where the code size of opkg needs to remain as small as 
possible. If you want to do any URL translation (including escapes), I'd 
recommend adding the code only for users of the curl backend instead. That 
would have the added advantage of being able to use the curl_easy_escape() 
function rather than implementing your own URL escaping.

If you need to continue using the wget backend, I'd recommend simply 
transforming the package file names when they are created so that they don't 
include problematic characters like '+'.

Thanks for submitting the patch though, it's good to know how other people are 
using opkg. In looking at this I've noticed '080-fix_gpgme_support.patch' in 
the same patches directory, I will check whether any of that needs merging into 
opkg.

Original comment by paul.betafive on 11 Jul 2014 at 11:26

• Changed state: Invalid

[GoogleCodeExporter]

Thank you for your prompt reply.

Sorry for having missed reading CONTRIBUTING. I understand why it may be 
inappropriate and I'm glad our issue raised your attention.

curl is a real option I have ignored so far: since we preinstall curl, we may 
probably just build opkg against libcurl.

The GPGME support patches were made by Fabio Di Nitto and should have already 
been merged in SHAs dda12e82bee20225625e2291391733fdc12371fc and 
b4721b128d79df19faab243653c3c8cfdbd2194d
We still use them because OpenWRT sticks with revision 618 of opkg.

Original comment by federico...@gmail.com on 11 Jul 2014 at 12:55

[GoogleCodeExporter]

You're correct - those changes have been merged.

I'd suggest trying to move forward to opkg v0.2.2 if you can - it solves a few 
other issues (notably issue 71, issue 91 and issue 107) which may affect your 
users.

Original comment by paul.betafive on 11 Jul 2014 at 1:00