On 2016-01-23 00:45, Arjen de Korte wrote: > Citeren Felix Fietkau <n...@openwrt.org>: > >> On 2016-01-22 22:29, edgar.sol...@web.de wrote: >>> On 22.01.2016 16:20, Felix Fietkau wrote: >>>> On 2016-01-22 16:03, edgar.sol...@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 That's an error handling bug - the hostname of the URL it redirects to is invalid. I've pushed a fix to uclient.git
> 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. I'll make an account and look into that soon. - Felix _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
