Summary: | net-misc/wget-1.14 - wget --http-keepalive hangs on non-supportive servers? | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | tte |
Component: | [OLD] Core system | Assignee: | Gentoo's Team for Core System packages <base-system> |
Status: | RESOLVED UPSTREAM | ||
Severity: | normal | ||
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | logfile from wget output |
i see no reason to revert this change because of one uncommon & buggy web server you can e-mail the upstream dev list and try to convince them if you like: https://lists.gnu.org/mailman/listinfo/bug-wget |
Created attachment 338008 [details] logfile from wget output problem: running wget-1.12-r3 for crucial scripts, works fine. Upgraded recently to 1.14. Scripts started to hang. Recompiling wget with debug showed that 1.14 seems to have HTTP keepalive enabled by default and seemingly the web server (powercycler with web server) did not support this, and so all automation failed. Or it could be a bug in wget. not sure. It was working again after adding "--no-http-keep-alive" to wget. a) I think that any wget version that defaults to HTTP keepalive should be masked unless there is a clear understanding that it will never lead to hanging. b) Would be good to ask upstream (wget) to change default to no http keep-alive and instead only enable HTTP keepalive when either the HTTP headers make it bulletproof that HTTP keepalives will work, or when there is automatic fallback to no-http-keepalive, or by explicitly specifying http keepalive as a command like option. Attached logfile with output of old (working) and new (broken) wget. Sorry. language of system was set to german.