On Sat, Sep 7, 2013 at 2:43 PM, Ángel González <[email protected]> wrote: > > On 06/09/13 21:21, Deepak Nagaraj wrote: >> >> Hi all, >> >> I found that GNU wget had no support for compressed file transfer. I have >> modified the code to: >> >> - send "Accept-Encoding: gzip" header >> - check if response is gzipped, and if so, decompress it at end of download >> - disable all related logic if --without-gzip is specified during configure > > Good. > [ ... ]
> > I'm not convinced about this. I would expect -z to *enable* zipping, not to > disable it. Given how unlikely it is to not desire gzipping, I would leave it > a long-option only. > I would even make it longer by not compressing "accept-encoding" into "ae". > gzip is enabled by default - the option is if you don't want this to happen (buggy server/proxy, testing, etc). I've expanded the arg. Please see attached (incremental) patch. > > You have a seemingly unrelated change to m4/wget.m4 It's ok, but please > explain why it was needed (and it should be added as a different change). > I was working on a FreeBSD 6.3 and an Ubuntu 13.04 system while making this change. One of them gave me problems - wget wouldn't even configure. I can't remember now but I can go check. This change fixed it. > I would prefer not to download the file and then decompress, but to > decompress it on-the-fly. Also, the rename will fail on windows with EEXIST. > If you feel lazy to use zlib directly, you could spawn gzip -d and filter the > file through it. I foresee some problems when continuing a download, but I > think there would be some with your patch already. > > OK, new change does this. There is another change in Makefile.am. This is because BSD flex does not accept a space between -o and file name. (It still works under Linux.) Let me know if you need the full patch (vs wget 1.14) and for any other comments. Also wget indent options, so that my changes don't stick out. Thanks, -deepak
wget-1.14-review1.patch
Description: Binary data
