Re: [Bug-wget] Support non-ASCII URLs

2016-01-12 Thread Giuseppe Scrivano
Eli Zaretskii  writes:

>> From: Tim Rühsen 
>> Cc: Giuseppe Scrivano , Eli Zaretskii 
>> Date: Fri, 18 Dec 2015 22:41:29 +0100
>> 
>> 1. Maybe do_conversion() should take a char * argument instead of const char 
>> *. We avoid one ugly const -> non-const cast an also a warning about iconv.
>
> I agree.
>
>> 2. contrib/check-hard fails with
>> TESTS_ENVIRONMENT="LC_ALL=tr_TR.utf8 VALGRIND_TESTS=0" make check
>> 
>> FAIL: Test-iri-forced-remote
>> 
>> My son has birthday tomorrow, so I am not sure how much time I can spend on 
>> the weekend on this issue. Maybe Eli or you could have a look ?
>
> I cannot bootstrap the Git repo (too many prerequisites I don't have).
> Can you or someone else produce a distribution tarball out of Git that
> I could then build "as usual"?
>
> Also, can you show me the log of the failed test?  Turkish locales
> have "an issue" with certain upper/lower-case characters, maybe that's
> the problem.  Or maybe it's something else; looking at the log might
> give good clues.

sorry for taking so long, this is the log I get when I run

$ TESTS_ENVIRONMENT="LC_ALL=tr_TR.utf8 VALGRIND_TESTS=0" make check

===
   wget 1.17.1.10-c78d: tests/test-suite.log
===

# TOTAL: 85
# PASS:  84
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: Test-iri-forced-remote


Unescaped left brace in regex is deprecated, passed through in regex; marked by 
<-- HERE in m/{{ <-- HERE port}}/ at HTTPServer.pm line 313.
Unescaped left brace in regex is deprecated, passed through in regex; marked by 
<-- HERE in m/{{ <-- HERE port}}/ at HTTPTest.pm line 50.
Running test Test-iri-forced-remote
Calling /home/gscrivano/src/wget/tests/../src/wget --iri -e robots=on 
--trust-server-names --remote-encoding=iso-8859-1 -nH -r http://localhost:36098/
--2016-01-12 12:11:57--  http://localhost:36098/
Resolving localhost (localhost)... 127.0.0.1
Connecting to localhost (localhost)|127.0.0.1|:36098... connected.
HTTP request sent, awaiting response... 200 Ok
Length: 279 [text/html]
Saving to: ‘index.html’

 0K   100% 30,8M=0s

2016-01-12 12:11:57 (30,8 MB/s) - ‘index.html’ saved [279/279]

Loading robots.txt; please ignore errors.
--2016-01-12 12:11:57--  http://localhost:36098/robots.txt
Reusing existing connection to localhost:36098.
HTTP request sent, awaiting response... 200 Ok
Length: unspecified [text/plain]
Saving to: ‘robots.txt’

 0K0,00 =0s

2016-01-12 12:11:57 (0,00 B/s) - ‘robots.txt’ saved [0]

--2016-01-12 12:11:57--  http://localhost:36098/p1_fran%C3%A7ais.html
Connecting to localhost (localhost)|127.0.0.1|:36098... connected.
HTTP request sent, awaiting response... 200 Ok
Length: 278 [text/html]
Saving to: ‘p1_français.html’

 0K   100% 32,7M=0s

2016-01-12 12:11:57 (32,7 MB/s) - ‘p1_français.html’ saved [278/278]

--2016-01-12 12:11:57--  http://localhost:36098/p3_%C2%A4%C2%A4%C2%A4.html
Reusing existing connection to localhost:36098.
HTTP request sent, awaiting response... 200 Ok
Length: 119 [text/plain]
Saving to: ‘p3_¤¤¤.html’

 0K   100% 13,9M=0s

2016-01-12 12:11:57 (13,9 MB/s) - ‘p3_¤¤¤.html’ saved [119/119]

--2016-01-12 12:11:57--  http://localhost:36098/p2_%C3%A9%C3%A9n.html
Reusing existing connection to localhost:36098.
HTTP request sent, awaiting response... 200 Ok
Length: 254 [text/html]
Saving to: ‘p2_één.html’

 0K   100% 26,2M=0s

2016-01-12 12:11:57 (26,2 MB/s) - ‘p2_één.html’ saved [254/254]

FINISHED --2016-01-12 12:11:57--
Total wall clock time: 0,09s
Downloaded: 5 files, 930 in 0s (26,0 MB/s)
Test failed: file p1_français.html not downloaded
FAIL Test-iri-forced-remote.px (exit status: 1)




Re: [Bug-wget] short option for --content-disposition (feature request)

2016-01-12 Thread Ángel González

On 05/01/16 14:34, Giuseppe Scrivano wrote:

Hanno Böck  writes:


Hi,

I quite often use the --content-disposition command line option of wget.
It's a bit annoying to type in, but currently it seems there is no
short option for it.
Could such a short option be added?

c and d are already taken and I think also all other characters in
content disposition. So I'd like to propose to use -z or -y (just
because they're not used yet and easy to remember), but I'd be okay
with any other char.

you can shorten long command line options specifying only a prefix if it
doesn't collide with another one, in your case you can specify
--content-d (since wget has --content-on-error as well).

Regards,
Giuseppe

As well as being able to set an alias in your shell for wget

--content-disposition or even set that option in your wgetrc so it applies by 
default, which is probably what you want.





Re: [Bug-wget] Support non-ASCII URLs

2016-01-12 Thread Eli Zaretskii
> From: Giuseppe Scrivano 
> Cc: tim.rueh...@gmx.de, bug-wget@gnu.org
> Date: Tue, 12 Jan 2016 20:58:16 +0100
> 
> Eli Zaretskii  writes:
> 
> > This was fixed by Tim in the meantime.  Are you running the current
> > Git version?
> 
> sorry my mistake, I was using an outdated version.  All works now for me
> as well.

Great, thanks for testing.



Re: [Bug-wget] Support non-ASCII URLs

2016-01-12 Thread Giuseppe Scrivano
Eli Zaretskii  writes:

> This was fixed by Tim in the meantime.  Are you running the current
> Git version?

sorry my mistake, I was using an outdated version.  All works now for me
as well.

Regards,
Giuseppe



Re: [Bug-wget] Support non-ASCII URLs

2016-01-12 Thread Eli Zaretskii
> From: Giuseppe Scrivano 
> Cc: Tim Rühsen , bug-wget@gnu.org
> Date: Tue, 12 Jan 2016 12:19:06 +0100
> 
> >> FAIL: Test-iri-forced-remote
> >> 
> >> My son has birthday tomorrow, so I am not sure how much time I can spend 
> >> on 
> >> the weekend on this issue. Maybe Eli or you could have a look ?
> >
> > I cannot bootstrap the Git repo (too many prerequisites I don't have).
> > Can you or someone else produce a distribution tarball out of Git that
> > I could then build "as usual"?
> >
> > Also, can you show me the log of the failed test?  Turkish locales
> > have "an issue" with certain upper/lower-case characters, maybe that's
> > the problem.  Or maybe it's something else; looking at the log might
> > give good clues.
> 
> sorry for taking so long, this is the log I get when I run
> 
> $ TESTS_ENVIRONMENT="LC_ALL=tr_TR.utf8 VALGRIND_TESTS=0" make check
> 
> ===
>wget 1.17.1.10-c78d: tests/test-suite.log
> ===
> 
> # TOTAL: 85
> # PASS:  84
> # SKIP:  0
> # XFAIL: 0
> # FAIL:  1
> # XPASS: 0
> # ERROR: 0
> 
> .. contents:: :depth: 2
> 
> FAIL: Test-iri-forced-remote

This was fixed by Tim in the meantime.  Are you running the current
Git version?



[Bug-wget] [bug #20523] wget ignores timeout on HTTPS connections

2016-01-12 Thread Andrey Mazo
Follow-up Comment #5, bug #20523 (project wget):

Just in case someone needs a test case for openssl_write() ignoring the
timeout, here it is.
Seems to be reproducible with wget-1.17.1.
It's quite unlikely to happen in the real world but anyway.

1) Make default TCP send buffer less than wget send buffer (which is 8192):

echo "4096 4096 4096" > /proc/sys/net/ipv4/tcp_wmem

2) Generate a sample file larger than TCP send buffer:

dd if=/dev/urandom of=./qqq.junk bs=10M count=1

3) Setup firewall rules to drop large outgoing packets to allow for successful
SSL handshake while blocking bulk uploads:

iptables -I OUTPUT -d  -m length --length 1000:1500 -j
DROP

4) Run wget to send bulk data:

wget --timeout=10 --tries=1 --post-file qqq.junk -O /dev/null
--no-check-certificate 'https://'

5) Observe wget ignoring the 10 second timeout.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/




[Bug-wget] [bug #20523] wget ignores timeout on HTTPS connections

2016-01-12 Thread Andrey Mazo
Follow-up Comment #6, bug #20523 (project wget):

Oh, sorry for the messed markup.
The same without markup:

1) Make default TCP send buffer less than wget send buffer (which is 8192):
echo "4096 4096 4096" > /proc/sys/net/ipv4/tcp_wmem

2) Generate a sample file larger than TCP send buffer:
dd if=/dev/urandom of=./qqq.junk bs=10M count=1

3) Setup firewall rules to drop large outgoing packets to allow for successful
SSL handshake while blocking bulk uploads:
iptables -I OUTPUT -d  -m length --length 1000:1500 -j
DROP

4) Run wget to send bulk data:
wget --timeout=10 --tries=1 --post-file qqq.junk -O /dev/null
--no-check-certificate 'https://'

5) Observe wget ignoring the 10 second timeout.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/