[Bug-wget] Update regarding FTP Test suite

Hello Everyone ! Darshit and I have been working on a FTP Server for Test suite. So far we have successfully build FTP server and integrated server with Wget Test file. Complete source code and commits are available here : [ https://github.com/satyamz/wget/tree/testing ] . To run the FTP Test su

[Bug-wget] About Proxy Command

Hi All, I would like to ask a question about proxy port usage with wget. I'm working on Automatic Check - Download application. I'm connecting to ftp server with special username and password and using 31281 port ( proxy ). Which command type should I use at this step? For example; Target ==> f

Re: [Bug-wget] [bug #45443] http_proxy variable should also work for capitalized HTTP_PROXY

On Tuesday 30 June 2015 11:20:28 Daniel Stenberg wrote: > On Tue, 30 Jun 2015, NoëlKöthe wrote: > > (Pruned the receivers list to the wget list only.) > > The reason some tools don't accept "HTTP_PROXY" and only "http_proxy" is > that the CGI interface from back in the old days provide headers fr

Re: [Bug-wget] [PATCH] the libidn problem

On Tuesday 30 June 2015 11:09:06 Hubert Tarasiuk wrote: > + while (*s) > +{ > + if ((*s & 0x80) == 0) /* 0xxx ASCII char */ > +s++; > + else if ((*s & 0xE0) == 0xC0) /* 110x 10xx */ > +{ > + if ((s[1] & 0xC0) != 0x80) > +return false;

Re: [Bug-wget] [bug #45443] http_proxy variable should also work for capitalized HTTP_PROXY

On Tue, 30 Jun 2015, NoëlKöthe wrote: (Pruned the receivers list to the wget list only.) The reason some tools don't accept "HTTP_PROXY" and only "http_proxy" is that the CGI interface from back in the old days provide headers from the incoming request to the CGI program prefixed with "HTTP_".

[Bug-wget] [bug #45443] http_proxy variable should also work for capitalized HTTP_PROXY

URL: Summary: http_proxy variable should also work for capitalized HTTP_PROXY Project: GNU Wget Submitted by: nok Submitted on: Di 30 Jun 2015 11:09:43 CEST Category: User Interface

Re: [Bug-wget] [PATCH] the libidn problem

+ while (*s) +{ + if ((*s & 0x80) == 0) /* 0xxx ASCII char */ +s++; + else if ((*s & 0xE0) == 0xC0) /* 110x 10xx */ +{ + if ((s[1] & 0xC0) != 0x80) +return false; + s+=2; +} + else if ((*s & 0xF0) == 0xE0) /* 1110

Re: [Bug-wget] the libidn problem

On 06/30/2015 10:24 AM, Daniel Stenberg wrote: I would assume that you first need to check that the input is claimed to be a UTF8 locale/encoding since I take it a user can use others and then your check shouldn't discard the input on the same premises. To do that, you need to use the same hue

Re: [Bug-wget] [PATCH] the libidn problem

On 06/30/2015 10:04 AM, Tim Ruehsen wrote: Thanks for the reminder, Daniel. Here is a patch for Wget. @Ander, just saw your mail when I was done with a patch. Please have a look, it just accepts 1-4 bytes sequences. I will. Thanks Tim. -- Regards, - AJ

Re: [Bug-wget] the libidn problem

On Tue, 30 Jun 2015, Ander Juaristi wrote: the library user (me, us, in this case) doesn't have to know anything about UTF-8, so we should rely on the library for everything UTF-8-related. I fully agree with this and I will stand by this rule. That's why I sent the "security notice" pointing

[Bug-wget] [PATCH] the libidn problem

Thanks for the reminder, Daniel. Here is a patch for Wget. @Ander, just saw your mail when I was done with a patch. Please have a look, it just accepts 1-4 bytes sequences. Regards, Tim On Monday 29 June 2015 23:14:39 Daniel Stenberg wrote: > Hi, > > The libidn issue that was previously reporte

Re: [Bug-wget] the libidn problem

On 06/29/2015 11:14 PM, Daniel Stenberg wrote: Hi, The libidn issue that was previously reported[1], is still outstanding and hasn't been fixed in libidn. This keeps wget vulnerable. I've just recommended[2] libcurl users to disable libidn until this gets resolved, as it seems it may drag on