[OpenWrt-Devel] uclient-fetch & SSL WAS:Re: DD: CONFIG_BUSYBOX_DEFAULT_WGET is not set
Arjen de Korte
arjen+openwrt at de-korte.org
Fri Jan 22 18:45:05 EST 2016
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
# /bin/uclient-fetch -O- 'http://de-korte.org/robots.txt'
Connecting to 2001:470:7ad2::10:80
It also behaves differently with the http://dyn.dns.he.net servers
(returning a Connection failure, despite also returning a result). See
# /bin/uclient-fetch -O-
Connecting to 2001:470:0:193::3000:443
Writing to stdout
nochg 22.214.171.124Connection 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'
Connecting to 2001:470:7ad2::10:443
Writing to stdout
(null) 100% |*******************************| 27
Download completed (27 bytes)
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
More information about the openwrt-devel