Re: [Bug-wget] Stepping down as maintainer

On Sat, 9 Jan 2010, Micah Cowan wrote: Well, folks, I think it's time for me to step down as Wget's maintainer. Micah, I think you can be proud of your time in the Wget lead. You clearly took it forward and you kept things in order and with style. Nice work! Are there any pending

Re: [Bug-wget] Potential bug or something else?

On Thu, 20 May 2010, Mike wrote: I have been downloading some pages off one of my sites, however I sometimes get two 4-digit hex codes appear in the HTML source: Here's the start of one page: 209b !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01//EN http://www.w3.org/TR/html4/strict.dtd;

Re: [Bug-wget] some quirks in current code

On Thu, 10 Jun 2010, Giuseppe Scrivano wrote: Does automake 1.11 work for you under Solaris? I don't know. I don't use Solaris myself so I'm reluctant to upgrade until I know it actually works. And honestly, I've not found any major problems with 1.9.x so I've simply stayed with it. --

Re: [Bug-wget] contributing to wget

On Fri, 11 Jun 2010, Giuseppe Scrivano wrote: Please change the type of the variable `ok' to `bool' and include this change in your patch, also include stdbool.h. Are you then dropping everything pre C99? I'm just curious as I thought wget traditionally aimed to work fine even with older

Re: [Bug-wget] security risk of unexpected download filenames

On Mon, 21 Jun 2010, Solar Designer wrote: As an alternative to copyright assignment to the FSF, perhaps Florian could simply place his changes in the public domain by unambiguously stating so on a public mailing list? I think that would save him time. Is that really a sound legal advice?

Re: [Bug-wget] Is WGET support Secured file transfer(SCP or SFTP)

On Fri, 13 Aug 2010, Muthu Sundaresan wrote: In the WGET man pages secured protocols like SFTP and SCP were not included in the list of protocols supported by WGET. Only FTP and HTTP were mentioned Please let me know whether WGET supports SFTP or not. Wget supports HTTP, HTTPS

Re: [Bug-wget] Can wget be used with cURL-created cookies file?

On Wed, 13 Oct 2010, oh...@cox.net wrote: So, I'm thinking that if wget is compatible with the cookies file that we get from cURL, we can use cURL for the authentication, followed by wget to retrieve the page + resources. Does anyone know if this'll work? Sure, curl outputs the cookies in

Re: [Bug-wget] Introduction

On Mon, 26 Sep 2011, Giuseppe Scrivano wrote: Since there's no FTP proxy standard or spec, how exactly is this going to work? ops, thanks to have pointed it out. I wasn't aware of it and I took it for granted. The bug report redirects to this discussion:

Re: [Bug-wget] Returning the http status

On Tue, 27 Sep 2011, Tim Pizey wrote: (For what it is worth curl appears to return unix status 0 for 404 pages, I can at least check for status 8 with wget) curl instead offers a rather fancy way of outputting selected information using its -w option, which could include the HTTP status.

Re: [Bug-wget] Support for long-haul high-bandwidth links

On Wed, 30 Nov 2011, Fernando Cassia wrote: When downloading a large file over a high-latency (e.g. long physical distance) high-bandwidth link, the download time is dominated by the round-trip time for TCP handshakes. First off, this early conclusion is incorrect. RTT has basically no

Re: [Bug-wget] Support for long-haul high-bandwidth links

On Thu, 1 Dec 2011, Andrew Daviel wrote: First off, this early conclusion is incorrect. RTT has basically no impact on an ongoing TCP transfer these days since they introduced large windows for like a decade ago. I may be wrong, but I thought that to get significant benefit large windows

Re: [Bug-wget] wget2.0 / niwt / refactoring

On Tue, 14 Aug 2012, Tim Ruehsen wrote: It shares no code with current Wget, AFAICT. 90% correct. I already rewrote the basic parts for Mget, so a big bunch of work is done. I'm far from sure about that. You rewrote significant portions of a 15+ years old project with lots of proven in

Re: [Bug-wget] [PATCH] Invalid Content-Length header in WARC files, on some platforms

On Wed, 14 Nov 2012, Tim Ruehsen wrote: as David Ryskalczyk stated, just two printf format specifiers might cause the havoc. I think, there is not need to use wgint instead of off_t. @Guiseppe: please apply the appended patches (maybe adding them together into one commit) Don't you still

Re: [Bug-wget] [PATCH] Invalid Content-Length header in WARC files, on some platforms

On Wed, 14 Nov 2012, Tim Ruehsen wrote: Taking this into account: is there any good point in not using long long ? The code is already polluted by c99 stuff. Right. I figure someone needs to decide where the compatibility line should be drawn. Hrvoje at least used to struggle to keep C89 and

[Bug-wget] C99 vs C89

On Sat, 17 Nov 2012, Giuseppe Scrivano wrote: Let's be realistic, is there any platform/system (with more than 3 users) where C99 is a problem? What parts of C99 are that attractive that you really need to use them and give up C89 compliance? I author and maintain several C libraries and

Re: [Bug-wget] Syntax for RESTful scripting options

On Tue, 5 Mar 2013, Ángel González wrote: wget --delete URL pointing to resource that must be deleted I would prefer something like --method=delete, which would also allow other methods (eg. OPTIONS, TRACE, PROPFIND...) Which incidentally is how curl does it (just with a differently named

Re: [Bug-wget] Syntax for RESTful scripting options

On Wed, 6 Mar 2013, Darshit Shah wrote: I intend to use the following logic in merging them: wget --method=POST [data/file] URL The text immediately following --method=POST is first assumed to be data. If however it does not exist in the key:value format, assume that to be a file path and

Re: [Bug-wget] Syntax for RESTful scripting options

On Thu, 7 Mar 2013, Darshit Shah wrote: The only reason I said that is, even currently wget only accepts post data in a key=value format.* Oh wow. I guess it proves I never use this feature with wget - no big surprise there probably. But I consider that to be a terrible limitation as well,

Re: [Bug-wget] [Bug-Wget] Use of maltipart/form-data when using body-file command

On Sun, 14 Apr 2013, Tim Rühsen wrote: I wanted to propose that we use Content-Type: multipart/form-data and send the whole file as-is when using the --body-file option. This allows us to add the long missing functionality to send files as attachments through wget, without having to change

Re: [Bug-wget] [Bug-Wget] Use of maltipart/form-data when using body-file command

On Tue, 16 Apr 2013, Tim Ruehsen wrote: The boundary string Giuseppe mentioned isn't really such a big deal if you ask me. You can easily make it in the same style as the browsers do it (a - prefix and a series of random letters) and if you like curl use 12 random hex letters it still

Re: [Bug-wget] Segmentation fault with current development version of wget

On Thu, 2 May 2013, Giuseppe Scrivano wrote: RFC 2606 doesn't seem very clear about it, and I can't find anywhere that PUT/OPTIONS/ANYTHING should be handled differently than POST wrt redirections. I don't see why suspending a PUT request would be incorrect. Darshit, do you have any pointer?

Re: [Bug-wget] [PATCH] replaced read_whole_file() by getline()

On Tue, 14 May 2013, Tim Rühsen wrote: But now that I made all the requested changes to my working tree, how do I make a diff to some commit back in time or to upstream ? Especially with git format-patch ? Locally, I didn't create my own branch, so i am on master. (I have to read a git book

Re: [Bug-wget] [Bug-Wget] Handling of Multiple authorizations

On Tue, 30 Jul 2013, Darshit Shah wrote: Even Curl I think does not support handling multiple auth schemes in one line, though I'm not completely sure of that. That's correct. I've never seen a live server send such a response and I've never seen a bug report about it either so I'm happily

Re: [Bug-wget] New option --no-list-a

On Fri, 30 Aug 2013, Tim Ruehsen wrote: Could you enlighten me about where '-a' comes from ? RFC 959 is very clear that a param after LIST is either a filename or a directory name. LIST -a basically works with the assumption that the server will detect that it looks like an option and run ls

Re: [Bug-wget] Race condition on downloaded files among multiple wget instances

On Tue, 3 Sep 2013, Tim Ruehsen wrote: but in general it is a good idea not to suppress errors or misbehavior, just to make people feel better. Then it should return an error and error message etc, it shouldn't crash with a SIGBUS... -- / daniel.haxx.se

Re: [Bug-wget] Race condition on downloaded files among multiple wget instances

On Tue, 3 Sep 2013, Tim Ruehsen wrote: There was an unexpected signal SIGBUS. It may be a bug or a misuse of Wget or your hardware is broken. Please think about it.. If you think SIGBUS is the ultimate way to inform a user about an error situation, then by all means do that. I wouldn't. --

Re: [Bug-wget] wget seems to be out of touch with security (fails on most (all?) http websites...(where browsers work)

On Fri, 20 Dec 2013, mancha wrote: This is not a wget issue proper. If it only warns and still continues and gets the content, I would still call it a problem. -- / daniel.haxx.se

Re: [Bug-wget] Overly permissive hostname matching

On Tue, 18 Mar 2014, Ángel González wrote: Daniel, how does cURL check correctness of the certificate hostname suffix? It insists on at least two dots. So yes, *.apple will cause problems for us too. I view the public suffix list as one of the worst kludges in networking history and while

Re: [Bug-wget] Overly permissive hostname matching

On Wed, 19 Mar 2014, Daniel Kahn Gillmor wrote: It insists on at least two dots. So yes, *.apple will cause problems for us too. There are also errors in the opposite direction: it sounds like curl will accept a cert for *.co.uk, right? Exactly, due to the lack of public suffix awareness!

Re: [Bug-wget] Overly permissive hostname matching

On Wed, 19 Mar 2014, Jeffrey Walton wrote: # Remove lines that begin with ! That sounds wrong: A rule may begin with a ! (exclamation mark). If it does, it is labelled as a exception rule and then treated as if the exclamation mark is not present. -- / daniel.haxx.se

Re: [Bug-wget] Overly permissive hostname matching

On Thu, 20 Mar 2014, Tim Rühsen wrote: I broke out the public suffix code together and created a first go (really very quick, distcheck fails - couldn't figure out this evening). https://github.com/rockdaboot/libpsl Ok, I'll be the first to rain on the parade. Sorry but it seems fit to do

Re: [Bug-wget] Overly permissive hostname matching

On Fri, 21 Mar 2014, Ángel González wrote: The LGPL would be an option. Not for curl though and probably not to other BSD/MIT licensed projects... -- / daniel.haxx.se

[Bug-wget] [PATCH] url: remove shorten_string

. */ static void append_char (char ch, struct growable *dest) -- 1.9.1 -- / daniel.haxx.seFrom 563ea99bca8c2ecb2674708fa909041d7e08a9df Mon Sep 17 00:00:00 2001 From: Daniel Stenberg dan...@haxx.se Date: Tue, 25 Mar 2014 11:56:58 +0100 Subject: [PATCH] url: remove shorten_string The function wasn't

[Bug-wget] daily clang analyzer scans of the wget sources

Hi I have this setup already for several other projects so I thought I'd do it for wget as well. So... I hereby offer daily clang-analyzer scans of the latest wget git sources. See: http://daniel.haxx.se/wget/ I'm letting the script keep a backlog of the last 20 runs. Right now it

Re: [Bug-wget] [RFC] Extend concurrency support

On Tue, 20 May 2014, Tim Ruehsen wrote: Not sure what other people think about it, but I think wget2, whatever it will be, should be based on libcurl and focus the wget development on what wget does better, eg recursive downloads. Libcurl is one option (and not the worst). At least it would

Re: [Bug-wget] [RFC] Extend concurrency support

On Wed, 21 May 2014, Tim Ruehsen wrote: libcurl offers a substantial amount of more functionality in the network layer than what wget has. And yes, libcurl has a DNS cache. As I understood Guiseppe, he wants to concentrate on FTP(S) and HTTP(S). Additional functionality like POP3, IMAP, ...

[Bug-wget] RFC 2616 is dead

Hey friends Just a FYI: HTTP 1.1 now has a new set of specs, see RFC7230 to RFC7235. The trusted and old 2616 is now obsolete... http://tools.ietf.org/html/rfc7230 http://tools.ietf.org/html/rfc7231 http://tools.ietf.org/html/rfc7232 http://tools.ietf.org/html/rfc7233

[Bug-wget] PATCH] main.c: update the --method description

Hi, The 'method' in a HTTP request is not part of a header, it is the request-line. See patch! -- / daniel.haxx.seFrom 75e193b01899f2280d9843e7a079c0679af148e5 Mon Sep 17 00:00:00 2001 From: Daniel Stenberg dan...@haxx.se Date: Wed, 23 Jul 2014 14:10:18 +0200 Subject: [PATCH] main.c: update

Re: [Bug-wget] wget and TLS 1.2

On Wed, 8 Oct 2014, Nikolay Morozov wrote: - OpenSSL modules must be initilized with OpenSSL_config(NULL), this enables cryto from OpenSSL modules f.ex GOST Please avoid using OpenSSL_config(), it is not a function I recommend anyone to use:

Re: [Bug-wget] SSL Poodle attack

On Wed, 15 Oct 2014, Daniel Kahn Gillmor wrote: I agree that OpenSSL has traditionally been too conservative. I'm arguing that if we're going to set anything other than the default, we should make our changes as *relative* changes rather than specifying something absolute, so that wget can

Re: [Bug-wget] [Bug-Wget] Patch Test-proxied-https-auth.px

On Thu, 30 Oct 2014, Tim Ruehsen wrote: How the test should work: - client open plain connection to proxy - client sends CONNECT request - server answers 200 OK - client/server change to SSL on the existing connection (in the real world the proxy does this when it established the requested

Re: [Bug-wget] let's fix the openssl backend once and for all

On Thu, 30 Oct 2014, Giuseppe Scrivano wrote: Do you think it would be possible to make a completely new library out of it? Maybe wget won't be the only user to take advantage of such library. I forgot, I also wrote about this topic a couple of years ago:

Re: [Bug-wget] let's fix the openssl backend once and for all

On Thu, 30 Oct 2014, Giuseppe Scrivano wrote: [1] = there would be some amount of work involved to make it happen, from both parties, but I think there would be mutual benefit. The code is somewhat separated in the libcurl code base already, but would need some further polish to get properly

Re: [Bug-wget] [Bug-Wget] Patch Test-proxied-https-auth.px

On Thu, 30 Oct 2014, Tim Ruehsen wrote: [*] = at least originally, until the MITM-ing proxies entered the scheme and complicated matters, but I prefer to view that as messed up SSL and not real SSL =) Yes, however, Wget has to be able to work with these (if users request it). From how I

Re: [Bug-wget] let's fix the openssl backend once and for all (was: Patch Test-proxied-https-auth.px)

On Thu, 30 Oct 2014, Giuseppe Scrivano wrote: and this remembers us that maintaining two different backends is not a good idea. I am for just moving to GNU TLS and forget about OpenSSL. It is a bit drastic but I think it is a better move for the long term. And we get rid of the copyright

Re: [Bug-wget] [Bug-Wget] Policy on commit messages

On Sat, 1 Nov 2014, Tim Rühsen wrote: If we move to detailed commit messages (I would appreciate it), then we should autogenerate ChangeLog files from the commit messages. You will find many projects out there already doing so. I would strongly support this as well. -- / daniel.haxx.se

Re: [Bug-wget] [PATCH] Fix some clang-analyzer warnings

On Wed, 19 Nov 2014, Darshit Shah wrote: I already have a few sanity checks for Wget in my pre-commit hook. Such things can be restyled for a server side update hook too. IMHO, it is better if you integrate those checks into the test suite or something so that contributors can figure them

Re: [Bug-wget] [PATCH] Fix possible issues running in a turkish locale

On Wed, 19 Nov 2014, Tim Rühsen wrote: I won't change my toolchain just to see these formfeeds. Looks like I had luck so far... but now, really, how can I work on Wget's sources from now on ? I have to stop here and now... Stop with that crap (formfeed characters) already. Exactly zero

[Bug-wget] [PATCH] remote_to_utf8: cut off part of condition always false

Hey Attached is a tiny patch that fixes a compiler warning as the right part of the condition always evaluates to true when a signed char is checked if it is larger than 127. -- / daniel.haxx.seFrom 15ef60d11b5444e005414ef513871de564eea18f Mon Sep 17 00:00:00 2001 From: Daniel Stenberg dan

Re: [Bug-wget] [PATCH] remote_to_utf8: cut off part of condition always false

On Fri, 21 Nov 2014, Daniel Stenberg wrote: Attached is a tiny patch that fixes a compiler warning as the right part of the condition always evaluates to true when a signed char is checked if it is larger than 127. Silly me, the patch title is correct. It always evaluates to *false

Re: [Bug-wget] ARRG (was: remote_to_utf8: cut off part of condition always false)

On Fri, 21 Nov 2014, Jakub Cajka wrote: You just make Wget fail on systems with char being unsigned (arm64, ppc64). That is the reason why this line has been introduced and the warning not being fixed !!! It was a bug fix some just weeks ago (I remember someone from Redhat !?). So please

Re: [Bug-wget] ARRG (was: remote_to_utf8: cut off part of condition always false)

78a8bd77da0864ca36d5f9b9478e2e28546e61ab Mon Sep 17 00:00:00 2001 From: Daniel Stenberg dan...@haxx.se Date: Fri, 21 Nov 2014 10:09:50 +0100 Subject: [PATCH] remote_to_utf8: check the host using unsigned chars --- src/iri.c | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git

Re: [Bug-wget] ARRG (was: remote_to_utf8: cut off part of condition always false)

On Fri, 21 Nov 2014, Tim Ruehsen wrote: Yes, but you don't need ustr. If you don't mind, I would apply this Ah yes, I certainly won't mind. Go ahead! -- / daniel.haxx.se

Re: [Bug-wget] [PATCH] Change testenv/Test-auth-both.py from XFAIL to a normal test

On Sat, 22 Nov 2014, Darshit Shah wrote: Multiple challenges in a single header are allowed. I had to hack a workaround in the Test suite explicitly to support this behaviour. Going down this route, you might enjoy this: http://greenbytes.de/tech/tc/httpauth/ -- / daniel.haxx.se

Re: [Bug-wget] [PATCH 1-3/3] support HTTP compression

On Wed, 17 Dec 2014, Ángel González wrote: + if (opt.compressed) +request_set_header (req, Accept-Encoding, gzip, deflate, rel_none); If we are also supporting compress and bzip2, they should be listed. bzip2 is not really used by servers to compress text content automatically so

Re: [Bug-wget] Use of 'ssl_st'

On Thu, 5 Feb 2015, Daniel Kahn Gillmor wrote: I've set up v...@lists.mayfirst.org and subscribed Darshit, Daniel, and myself to the mailing list for this discussion. Lovely, thanks! I also mentioned it on twitter and on the libcurl mailing list. I'll give people some time to find it and get

Re: [Bug-wget] Use of 'ssl_st'

On Thu, 5 Feb 2015, Daniel Kahn Gillmor wrote: i can spin up a mailing list if that would be useful. I think i'm also not on the curl lists, so please cc me as well until we sort out the right place to have the discussion. Hey, I think it would be valuable to take to a new place so that

Re: [Bug-wget] [PATCH] maint: update copyright year ranges to include 2015

On Mon, 9 Mar 2015, Ángel González wrote: Unless the file was changed in that year (with copyrightable changes), AFAIK the copyright year wouldn't change, no matter what the label says. I would agree would you, but the GNU policy is different[1]: It is recommended and simpler to add the

Re: [Bug-wget] GSoC15: Speed up Wget's Download Mechanism

On Thu, 30 Apr 2015, Gisle Vanem wrote: Hard to tell since I didn't find any large files I could D/L via SSL. You have one? But some quick tests (only a 48 kByte file): Here's a HTTPS URL that gives you a 40651008 bytes Firefox installation:

Re: [Bug-wget] GSoC15: Speed up Wget's Download Mechanism

On Thu, 30 Apr 2015, Tim Ruehsen wrote: Originally, Gisle talked about CPU cycles, not elapsed time. That is quite a difference... Thousands of cycles per invoke * many invokes = measurable elapsed time -- / daniel.haxx.se

Re: [Bug-wget] [GSoC 2015] Basic HTTP/2 support

On Fri, 1 May 2015, Miquel Llobet wrote: Do you suggest starting off with HTTPS first then? Yes sure if you want to get something going first, and then using both NPN and ALPN for maximum compliance at least for now. It seems like most client/browsers only plan to support HTTPS. Firefox

Re: [Bug-wget] [GSoC 2015] Basic HTTP/2 support

On Thu, 30 Apr 2015, Miquel Llobet wrote: I'm glad to see this project come to life, and I'm happy to see you chosing to base it on Tatsuhiro's awesome nghttp2 library. We do this in the curl project too. I blame Giuseppe for suggesting it :-), and nghttp2 looks really good, can't wait to

Re: [Bug-wget] Contribution on bug #45037

On Mon, 18 May 2015, Ander Juaristi wrote: What's more, in the case of OpenSSH SFTP, this seems to be the only behaviour and does not seem to be overridable. Chances are other FTP servers mimic this behaviour. OpenSSH SFTP is not an FTP server though... -- / daniel.haxx.se

Re: [Bug-wget] no_proxy env ip address range support

On Tue, 14 Apr 2015, Aníbal Limón wrote: I noticed that wget only support domain names entries into no_proxy env-var, i think will be good to add support for IPs and IP ranges. Let me just remind everyone that a very common setup for people behind proxies like in large companies, is to not

Re: [Bug-wget] Getting wget to work with libressl - anyone already working on this?

On Tue, 16 Jun 2015, Michael Felt wrote: Before looking into what may be needed to use libressl rather than openssl or gettls I wanted to check that noone else is already looking into this. Will check back later :) Have you tried building with it? libressl is really quite good at keeping

Re: [Bug-wget] TCP Fast Open for HTTP

On Thu, 28 May 2015, Tim Rühsen wrote: BTW, an alternative might be QUIC (http://en.wikipedia.org/wiki/QUIC). QUIC approaches the same problem (RTT). But it seems far from being standardized though there seems support in Apache and Nginx. Support in Apache and Nginx, really? Any

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

Re: [Bug-wget] the libidn problem

On Thu, 2 Jul 2015, Giuseppe Scrivano wrote: This is the reply I got: http://lists.gnu.org/archive/html/help-libidn/2015-07/msg0.html I don't like much the You need to pass valid UTF-8 to libidn in there. I think it shows a misunderstanding on how we (want to) use libidn... -- /

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] the libidn problem

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 and keeping vulnerable code around is not

Re: [Bug-wget] Truncated files ... --ignore-length bug ??

On Wed, 12 Aug 2015, Darshit Shah wrote: The server responds with a HTTP 200 response, so it is not returning only partial content / attempting to stream. The way Wget reads that response is that the server has sent all the data it had. This server is clearly not behaving correctly. It

Re: [Bug-wget] WGET version for SFTP Connection + ftp-callback functionality

On Fri, 24 Jul 2015, Pravin B Kudle wrote: now we have to do the SFTP connection to mirror the files but on internet I am not getting the WGET version which supports the SFTP connection plus --ftp-callback functionality. wget does not support SFTP at all. -- / daniel.haxx.se

Re: [Bug-wget] Wget 1.17 doesn't compile on Windows (hsts.c)

On Tue, 17 Nov 2015, Tim Ruehsen wrote: BTW, I am pretty astonished that there are no Windows developers ever trying to compile Wget before any release. How can we any longer support an OS without any help from OS users ? Cross-compilation and testing with Wine is IMO not an option... I had

Re: [Bug-wget] [GSoC 2015] Basic HTTP/2 support

On Thu, 30 Apr 2015, Daniel Stenberg wrote: Did anything happen with this project? -- / daniel.haxx.se

Re: [Bug-wget] [bug #47408] Wget sends malformed SNI host names

On Wed, 16 Mar 2016, Tim Ruehsen wrote: Should we follow the browsers or curl ? I brought this subject to the http-wg mailing list, possibly we can clear it up on a wider scale: https://lists.w3.org/Archives/Public/ietf-http-wg/2016JanMar/0430.html -- / daniel.haxx.se

Re: [Bug-wget] Anyone want to add libcares support to wget?

On Tue, 15 Mar 2016, Tim Ruehsen wrote: You want the DNS UDP packets being sent with src=88.1.1.10 and dst=(88.2.1.1,88.2.1.2)... this means using the interface 88.1.1.10. IMO, this is a routing (and resolv.conf) issue. Not if you want to do it for an individual application. The routing

Re: [Bug-wget] [bug #47408] Wget sends malformed SNI host names

On Wed, 16 Mar 2016, Jay Satiro wrote: I tried this in Firefox, Chrome and IE and all send the trailing dot for SNI. curl doesn't though, it strips the trailing dot and also it won't appear in the host header. And the associated Firefox bug report:

Re: [Bug-wget] [bug #47408] Wget sends malformed SNI host names

On Wed, 16 Mar 2016, Tim Ruehsen wrote: Here is a patch for both openssl and gnutls. Please comment, I'll push it tomorrow. The bug report says the SNI field should be different than the Host: header, but I question the sensibility in that. What would be the point? (pun not intended =B))

Re: [Bug-wget] [PATCH] Anyone want to add libcares support to wget?

On Sun, 20 Mar 2016, Tim Rühsen wrote: Here comes the first version of the patch. The c-ares library is called libcares.(a|so) when you install it from the c-ares sources. The ares library installs libares. So I think you want to detect libcares in configure etc. c-ares is a fork of the

Re: [Bug-wget] Fwd: Saving Cookies issue

On Tue, 2 Aug 2016, Tim Ruehsen wrote: But the Firebug extension (for Firefox) is also a good choice. Not sure about Chrome/Chromium. Both Firefox and Chrome have pretty good internal devtools that can show all incoming/outgoing requests and headers, so there's rarely a need for any

[Bug-wget] gnutls_handshake can return GNUTLS_E_INTERRUPTED

Hello, gnutls_handshake() is documented to possibly return GNUTLS_E_INTERRUPTED as well as GNUTLS_E_AGAIN and should probably behave similarly for both return codes within wget. diff --git a/src/gnutls.c b/src/gnutls.c index 63c7c33..44c497b 100644 --- a/src/gnutls.c +++ b/src/gnutls.c @@

Re: [Bug-wget] gnutls_handshake can return GNUTLS_E_INTERRUPTED

On Thu, 30 Jun 2016, Tim Ruehsen wrote: I believe, we already handle that case. If GNUTLS_E_INTERRUPTED occurs, we restart the loop and re-enter gnutls_handshake(). This happens for all non-fatal errors. Right, but then it won't wait for the socket and just busy-loop. The

Re: [Bug-wget] gnutls_handshake can return GNUTLS_E_INTERRUPTED

On Fri, 1 Jul 2016, Tim Ruehsen wrote: GNUTLS_E_INTERRUPTED is returned if the process got a signal that interrupts blocking I/O (for wget this is SIGUSR1 and SIGHUP). If it is just *one* signal (very likely), a successive call to gnutls_handshake() would not return again with this value. If

[Bug-wget] CII best practices for wget?

Hey, The Core Infrastructure Initiative runs a project[1] to have free and open source projects register to get a "best practises" badge by filling in a form telling the world about what practises and procedures the project has and uses. The idea being to A) make sure more projects do the

Re: [Bug-wget] New wget (1.19.2): Unexpected download behaviour for gzip-compressed tarballs (HTTP-header dependent)

On Wed, 1 Nov 2017, Tim Rühsen wrote: Content-Encoding: gzip means that the data has been compressed for transportation purposes only. That's actually not what it means. There's transfer-encoding for that purpose, but that's not generally supported by clients. RFC7231 section 3.1.2.1 [*]

Re: [Bug-wget] New wget (1.19.2): Unexpected download behaviour for gzip-compressed tarballs (HTTP-header dependent)

On Thu, 2 Nov 2017, Tim Rühsen wrote: How would you (or curl) handle Content-Type: application/x-tar Content-Encoding: gzip when downloading 'x.tar.gz' or 'x.tgz' ? Save the file compressed or uncompressed ? And what if the file is (correctly) named 'x.tar' ? Fortunately for me, curl

Re: [Bug-wget] [curlsec] [USN-3464-1] Wget vulnerabilities

hed but curl team doesn't think it's a vulnerability? https://www.blackhat.com/docs/us-17/thursday/us-17-Tsai-A-New-Era-Of-SSRF-Exploiting-URL-Parser-In-Trending-Programming-Languages.pdf On Sun, Oct 29, 2017 at 3:35 PM, Daniel Stenberg <dan...@haxx.se> wrote: On Sun, 29 Oct 2017, Kris

Re: [Bug-wget] About GSoC project: Support QUIC Protocol

On Fri, 9 Mar 2018, Jay Bhavsar wrote: I am considering to apply for "Support QUIC Protocol". I have read this specification, and understood most of it. Hi Jay, The QUIC protocol of the future is the one

Re: [Bug-wget] About GSoC project: Support QUIC Protocol

On Fri, 9 Mar 2018, Gisle Vanem wrote: I agree on ngtcp2. Foremost because it seems to have good support for MSVC/Windows. My next contender would be MozQuic. Written in C++, but with C interface. A bit of a bummer for Wget2 or libcurl? I personally believe a lot in ngtcp2 much due to its

Re: [Bug-wget] GSoC'18: DNS over HTTPS.

On Thu, 22 Mar 2018, Aniketh Gireesh wrote: Thanks Daniel for your inputs, I guess you would be okay if I contact you when get stuck somewhere during the implementation part/coding period. ;) Absolutely. I'll try to help out and respond if I can and time permits! Please do let me know if I

Re: [Bug-wget] [PATCH] NTLM restart authentication

On Sat, 29 Dec 2018, Tim Rühsen wrote: But anyways, I would like to ask Daniel Stenberg if he agrees if that copy of code is being copyrighted by the FSF. Only if he agrees, I would add this patch. That is just a matter of politeness and correctness. The commit message would explain it's

Re: [Bug-wget] Pha support for tls1.3

On Fri, 22 Mar 2019, Tim Rühsen wrote: Are you sure that '#ifdef SSL_CTX_set_post_handshake_auth' works ? Here with OpenSSL 1.1.1b it seems that 'SSL_CTX_set_post_handshake_auth' is a function and not a #define. In curl we use this #ifdef magic for figuring out if the function is present:

Re: [Bug-wget] Does wget has the "outstanding read data" problem?

On Fri, 17 May 2019, Peng Yu wrote: curl has this problem "(18) transfer closed with outstanding read data remaining". Does wget have a similar problem like this? Thanks. That's not a "problem" curl has. That's a feature. It detects prematurely cut off transfers when receiving chunked

Re: [Bug-wget] Does wget has the "outstanding read data" problem?

On Sat, 18 May 2019, Tim Rühsen wrote: The connection is closed prematurely and you do not want to re-download everything. Wget has -c / --continue for that. I could be noted that transfers with chunked encoding are rarely resumable. -- / daniel.haxx.se

Re: Wget: Adding a prefix to downloaded files?

On Tue, 17 Dec 2019, Tim Rühsen wrote: wget has no parallel processing. Wget2 has. This phrasing could use some clarity. Does this mean that Wget2 is not Wget? Is 'Wget2' the name of a separate tool/project? Or is Wget2 actually Wget version 2? Because if it is, then Wget has parallel

Re: Huge POST requests with WGET & "multipart/form-data"

On Sun, 1 Dec 2019, Taylor wrote: * Is there some other simple HTTPS program that can do it (I need HTTPS/TLS, cookies, and huge POST "multipart/form-data") ? I'm not sure it counts as "simple", but curl can - and it streams the POST so it can actually send data with virtually unlimited

[bug #58354] Wget doesn't parse URIs starting with http:/

Follow-up Comment #3, bug #58354 (project wget): Note that the browser's The WHATWG URL Spec (TWUS) allows that kind of abomination, while RFC 3986 explicitly requires two slashes to be there. (Listed in my "URL interop" page at https://github.com/bagder/docs/blob/master/URL-interop.md) In fact,

Re: Does wget support SOCKS proxy?

On Wed, 13 Jan 2021, Peng Yu wrote: I know the environment variables of http_proxy and https_proxy. But I don't know whether they can be used for SOCKS proxy or not because the manpage does not mention any keywords of SOCKS. To the best of my knowledge, wget doesn't support SOCKS natively

Re: Semicolon not allowed in userinfo

On Tue, 3 Oct 2023, Tim Rühsen wrote: My version of curl (8.3.0) doesn't accept it: curl -vvv 'http://a ;b:c@xyz' * URL rejected: Malformed input to a URL function That's in no way a legal URL (accortding to RFC 3986) and it is not the semicolon that causes curl to reject it. It is the