[OpenWrt-Devel] uclient-fetch & SSL WAS:Re: DD: CONFIG_BUSYBOX_DEFAULT_WGET is not set

[Arjen de Korte]

Citeren Felix Fietkau <nbd at openwrt.org>:

> On 2016-01-22 22:29, edgar.soldin at web.de wrote:
>> On 22.01.2016 16:20, Felix Fietkau wrote:
>>> On 2016-01-22 16:03, edgar.soldin at web.de wrote:
>>>> On 22.01.2016 14:32, Weedy wrote:
>>>>>> Question: The busybox binary (for me) goes from 366,401 bytes to 300,327
>>>>> with the removal of wget from it.  Therefore, the uclient-fetch binary
>>>>> swapout causes a 46,379 byte increase in size. I assume the  
>>>>> desire to move
>>>>> to uclient-fetch from busybox is for the SSL support?  If so, it  
>>>>> still does
>>>>> not support SSL without also building ustream-ssl.
>>>>
>>>> yeah. an ssl capable wget (whatever it's called) out of the box  
>>>> would be greatly appreciated.
>>>>
>>>> @Felix: is that on the table?
>>> It's already done. With uclient-fetch, you can simply install any
>>> ustream-ssl variant (along with ca-certificates if you want to have
>>> proper validation), and it'll immediately be SSL capable. That was my
>>> main motivation behind replacing wget with ustream-ssl.
>>>
>>> The aforementioned size increase is probably either a bug or a
>>> measurement error (see my other mail regarding that subject).
>>>
>>
>> nice! is there a possibility to create a wget wrapper? i assume not
>> everyone is familiar with uclient-fetch, so at least a stub noting to
>> use uclient-fetch might probably help when users are confused that wget
>> isn't there.
> You keep asking for things that are already there :)
>
> The uclient-fetch package provides a symlink to wget and it is fully
> command line compatible as well. Users don't have to change their habits
> and scripts that don't hardcode the path will continue to work as well.

Not entirely. It (r48456) segfaults on receiving a 301 redirect for  
http->https:

# /bin/uclient-fetch -O- 'http://de-korte.org/robots.txt'
Downloading 'http://de-korte.org/robots.txt'
Connecting to 2001:470:7ad2::10:80
Segmentation fault

It also behaves differently with the http://dyn.dns.he.net servers  
(returning a Connection failure, despite also returning a result). See  
below:

# /bin/uclient-fetch -O-  
'https://dyn.dns.he.net/nic/update?hostname=example.com&password=munged&myip=1.2.3.4'
Downloading  
'https://dyn.dns.he.net/nic/update?hostname=example.com&password=munged&myip=1.2.3.4'
Connecting to 2001:470:0:193::3000:443
Writing to stdout
nochg 1.2.3.4Connection error: Connection failed

I'm not too concerned about the first, but the latter is a bit  
inconvenient. I suspect the HE servers close the connection  
immediately after sending the result and that this is not expected.  
For example, the following works as expected:

# /bin/uclient-fetch -O- 'https://de-korte.org/robots.txt'
Downloading 'https://de-korte.org/robots.txt'
Connecting to 2001:470:7ad2::10:443
Writing to stdout
User-agent: *
Disallow: /

(null)               100% |*******************************|    27    
0:00:00 ETA
Download completed (27 bytes)

Regards, Arjen
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel