[bug #65007] wget uses non-standard way to print IPv6 addresses

Follow-up Comment #2, bug#65007 (group wget): > I see that in wget2 the output is also not quite correct in the debug logs. Indeed, wget2's debug output contains 10.124503.288 has 2a02:6ea0:c700::18:443 10.124503.288 trying 2a02:6ea0:c700::18:443...

[bug #65007] wget uses non-standard way to print IPv6 addresses

erface Severity: 3 - Normal Priority: 5 - Normal Status: None Privacy: Public Assigned to: None Originator Name: Bruno Haible Originator Email: Open/Closed: Open Release

Re: implicit declaration of function 'utime' in trailing slashes test

at is > by the function declaration. This is well-known for 'float' parameters (for a long time, on most platforms). Do you happen to know other cases for which this is the case? I'm asking in order to check GNU libffcall and libffi w.r.t. this situation. Bruno 2021-01-23 Bruno Haible

Re: wget 1.21.1 configuration

Hi Tim, > > You can use m4_pattern_forbid([AX_]) to guard against such mistakes. > > Well, I might be too stubborn for this. Adding it results in > > configure:20848: error: possibly undefined macro: INTMAX_MAX >If this token and others are legitimate, please use m4_pattern_allow. >

wget 1.21.1 configuration

The configure script apparently references an undefined macro: $ ./configure ... checking for stdint.h... (cached) yes ./configure: line 51273: AX_CODE_COVERAGE: command not found checking for working mmap... yes ... You can use m4_pattern_forbid([AX_]) to guard against such mistakes. Bruno

Re: Bootstrap with old Python

[Redirected from bug-gnulib] Jeffrey Walton wrote: > > Yeah, I wish Tim would build a release tarball so we don't have to do > > the git submodule thing. Darshit Shah replied: > We can work on that soon. Wget2 _is_ technically still alpha software. > And with both Tim and me busy with real

Re: [bug #57884] wget reveals my operating system to the server

ge...@mweb.co.za wrote: > I wonder about the reason given: "To avoid compatibility issues." > That was - if I recall correctly - the reason for having the string > to start with: So that servers can format pages to suit the capabilities > of the browser and version used. That was how web

[bug #57884] wget reveals my operating system to the server

Follow-up Comment #4, bug #57884 (project wget): The HTTP 1.1 RTC, section 5.5.3 https://tools.ietf.org/html/rfc7231#section-5.5.3 , says that the version number is optional, and """A user agent SHOULD NOT generate a User-Agent field containing needlessly fine-grained detail ... Overly long and

[bug #57884] wget reveals my operating system to the server

Follow-up Comment #3, bug #57884 (project wget): What about the version number? It can reveal whether a system is regularly patched or not. A string like "User-Agent: Wget/1.10.2" would be an invitation to search for security vulnerabilities on all ports of the machine.

[bug #57884] wget reveals my operating system to the server

Follow-up Comment #1, bug #57884 (project wget): See the attached screenshot: "User-Agent: Wget/1.19.1 (linux-gnu)" is too much private info. ___ Reply to this item at:

[Bug-wget] [bug #48193] Build fails unless -liconv set explicitly in LDFLAGS

Follow-up Comment #9, bug #48193 (project wget): Rather than LDADD = $(LIBOBJS) $(LTLIBICONV) ../lib/libgnu.a it would be better to write LDADD = $(LIBOBJS) ../lib/libgnu.a $(LTLIBICONV) The reason is that $(LTLIBICONV) refers to - more or less - a system library, and it can be a shared