Re: read error
On 1/11/24 05:40, 王强 via Primary discussion list for GNU Wget wrote: Wget is consistently encountering a byte read error, increasing the number of attempts and the waiting time does not solve the problem. （2024-01-11 12:37:20 (17.3 KB/s) - Read error at byte 2122610 (Success).Retrying.） url：https://zinc15.docking.org/substances/subsets/in-trials.sdf?count=all Thanks for the report. Just to confirm: The issue is reproducible with wget 1.21.4 on Linux. The download works as expected with wget2 2.1.0. Regards, Tim OpenPGP_signature.asc Description: OpenPGP digital signature
read error
Wget is consistently encountering a byte read error, increasing the number of attempts and the waiting time does not solve the problem. ??2024-01-11 12:37:20 (17.3 KB/s) - Read error at byte 2122610 (Success).Retrying.?? url??https://zinc15.docking.org/substances/subsets/in-trials.sdf?count=all
[bug #58525] HTTP request sent, awaiting response... Read error (Bad file descriptor) in headers.
Follow-up Comment #1, bug #58525 (project wget): Running in --debug mode I got some more details: ... Initiating SSL handshake. seconds 900,00, Winsock error: 0 Handshake successful; connected socket 3 to SSL handle 0x03106e00 certificate: subject: CN=orc.amd.com,O=Advanced Micro Devices,L=Austin,ST=Texas,C=US issuer: CN=GeoTrust RSA CA 2018,OU=www.digicert.com,O=DigiCert Inc,C=US X509 certificate successfully verified and matches host drivers.amd.com ... HTTP request sent, awaiting response... seconds 900,00, Winsock error: 0 ---response begin--- HTTP/1.1 302 Moved Temporarily Server: AkamaiGHost Content-Length: 0 Location: https://www.amd.com/de/support/kb/faq/download-incomplete Date: Sun, 07 Jun 2020 20:51:20 GMT Connection: keep-alive ---response end--- ... Converted file name 'Win10-Radeon-Software-Adrenalin-2020-Edition-20.5.1-May27.exe' (UTF-8) -> 'Win10-Radeon-Software-Adrenalin-2020-Edition-20.5.1-May27.exe' (CP1252) --2020-06-07 22:50:34-- https://www.amd.com/de/support/kb/faq/download-incomplete Resolving www.amd.com (www.amd.com)... seconds 0,00, 92.123.252.55 Caching www.amd.com => 92.123.252.55 Connecting to www.amd.com (www.amd.com)|92.123.252.55|:443... seconds 0,00, connected. Created socket 4. Releasing 0x0311ae90 (new refcount 1). Initiating SSL handshake. seconds 900,00, Winsock error: 0 Handshake successful; connected socket 4 to SSL handle 0x03124870 certificate: subject: CN=amd.com,OU=MARKETING,O=Advanced Micro Devices,L=Austin,ST=Texas,C=US issuer: CN=GeoTrust RSA CA 2018,OU=www.digicert.com,O=DigiCert Inc,C=US X509 certificate successfully verified and matches host www.amd.com ---request begin--- GET /de/support/kb/faq/download-incomplete HTTP/1.1 User-Agent: Wget/1.19.4 (mingw32) Accept: */* Accept-Encoding: identity Host: www.amd.com Connection: Keep-Alive ---request end--- HTTP request sent, awaiting response... Read error (error:0B07C065:x509 certificate routines:X509_STORE_add_cert:cert already in hash table; error:0B07C065:x509 certificate routines:X509_STORE_add_cert:cert already in hash table) in headers. Closed 4/SSL 0x03124870 Retrying. --2020-06-07 22:50:54-- (try: 2) https://www.amd.com/de/support/kb/faq/download-incomplete Found www.amd.com in host_name_addresses_map (0311ae90) Connecting to www.amd.com (www.amd.com)|92.123.252.55|:443... seconds 0,00, connected. Created socket 4. Releasing 0x0311ae90 (new refcount 1). Initiating SSL handshake. seconds 900,00, Winsock error: 0 Handshake successful; connected socket 4 to SSL handle 0x03123410 certificate: subject: CN=amd.com,OU=MARKETING,O=Advanced Micro Devices,L=Austin,ST=Texas,C=US issuer: CN=GeoTrust RSA CA 2018,OU=www.digicert.com,O=DigiCert Inc,C=US X509 certificate successfully verified and matches host www.amd.com ---request begin--- GET /de/support/kb/faq/download-incomplete HTTP/1.1 User-Agent: Wget/1.19.4 (mingw32) Accept: */* Accept-Encoding: identity Host: www.amd.com Connection: Keep-Alive ---request end--- HTTP request sent, awaiting response... ^C ___ Reply to this item at: <https://savannah.gnu.org/bugs/?58525> ___ Message sent via Savannah https://savannah.gnu.org/
[bug #58525] HTTP request sent, awaiting response... Read error (Bad file descriptor) in headers.
URL: <https://savannah.gnu.org/bugs/?58525> Summary: HTTP request sent, awaiting response... Read error (Bad file descriptor) in headers. Project: GNU Wget Submitted by: gnats Submitted on: Sun 07 Jun 2020 08:49:53 PM UTC Category: Protocol Issue Severity: 3 - Normal Priority: 5 - Normal Status: None Privacy: Public Assigned to: None Originator Name: Originator Email: Open/Closed: Open Release: 1.20 Discussion Lock: Any Operating System: Microsoft Windows Reproducibility: Every Time Fixed Release: None Planned Release: None Regression: None Work Required: None Patch Included: None ___ Details: I have this reproducible issue with downloads from AMD (Radeon driver) in Windows 10 (64-bit) (binary from https://eternallybored.org/misc/wget/): wget-1.20.3-win32>wget -N https://drivers.amd.com/drivers/beta/Win10-Radeon-Software-Adrenalin-2020-Edition-20.5.1-May27.exe --2020-06-07 22:33:11-- https://drivers.amd.com/drivers/beta/Win10-Radeon-Software-Adrenalin-2020-Edition-20.5.1-May27.exe Resolving drivers.amd.com (drivers.amd.com)... 2.22.69.4 Connecting to drivers.amd.com (drivers.amd.com)|2.22.69.4|:443... connected. HTTP request sent, awaiting response... 302 Moved Temporarily Location: https://www.amd.com/de/support/kb/faq/download-incomplete [following] --2020-06-07 22:33:11-- https://www.amd.com/de/support/kb/faq/download-incomplete Resolving www.amd.com (www.amd.com)... 92.123.252.55 Connecting to www.amd.com (www.amd.com)|92.123.252.55|:443... connected. HTTP request sent, awaiting response... Read error (error:0B07C065:x509 certificate routines:X509_STORE_add_cert:cert already in hash table; error:0B07C065:x509 certificate routines:X509_STORE_add_cert:cert already in hash table) in headers. Retrying. --2020-06-07 22:33:31-- (try: 2) https://www.amd.com/de/support/kb/faq/download-incomplete Connecting to www.amd.com (www.amd.com)|92.123.252.55|:443... connected. HTTP request sent, awaiting response... Read error (Bad file descriptor) in headers. Retrying. --2020-06-07 22:33:53-- (try: 3) https://www.amd.com/de/support/kb/faq/download-incomplete Connecting to www.amd.com (www.amd.com)|92.123.252.55|:443... connected. HTTP request sent, awaiting response... Read error (Bad file descriptor) in headers. Retrying. --2020-06-07 22:34:15-- (try: 4) https://www.amd.com/de/support/kb/faq/download-incomplete Connecting to www.amd.com (www.amd.com)|92.123.252.55|:443... connected. HTTP request sent, awaiting response... Read error (Bad file descriptor) in headers. Retrying. ^C ___ Reply to this item at: <https://savannah.gnu.org/bugs/?58525> ___ Message sent via Savannah https://savannah.gnu.org/
Re: [Bug-wget] Read error (Success)?
On 20.11.18 16:29, Dale R. Worley wrote: > "Tony Lewis" writes: >> I'm getting the following error and don't understand what it's trying to >> tell me: >> >> Read error at byte 97430 (Success) >> >> What could the server be doing to cause wget to report an error with the >> details being "Success"? > > My guess is that the server's response starts with a message including > the description "Success". No, it usually comes from a situation where some error is detected and the string representing the value of "errno" is output, but "errno" does not reflect the error and is 0 -> "Success". Try printing "strerror(0)": "Success". Josef
Re: [Bug-wget] Read error (Success)?
First, I can assure you the server is NOT sending "Success"; anyway, according to http.c, the bit between the parentheses comes from hstat.rderrmsg. For the run that is described below the output file has a size of 962378. This is the only page on the server that has this problem and the exact same page works fine when running the same code on another domain on the same server. The configuration data that is being presented to the user differs between the two servers, but whatever is causing it to fail is happening after the configuration has been output. In case it helps: WordPress runs the shutdown action including calling wp_ob_end_flush_all from /wp-includes/functions.php. I'll give you information as much as I can, but one must be logged into the site as an administrator to access the page. I saved the cookies from the last request in Chrome. wget -dSv --load-cookies=cookies.txt --tries=1 --user-agent="Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.77 Safari/537.36" "https://www.robertrudelic.com/wp-admin/options-general.php?page=exelana_kic k_start_cart_settings_page=exksc_tab_products" -O tab_products.html And here is the output minus the cookies. DEBUG output created by Wget 1.19.5 on darwin18.2.0. --2018-11-20 10:57:22-- https://www.robertrudelic.com/wp-admin/options-general.php?page=exelana_kick _start_cart_settings_page=exksc_tab_products Resolving www.robertrudelic.com (www.robertrudelic.com)... 23.229.205.103 Caching www.robertrudelic.com => 23.229.205.103 Connecting to www.robertrudelic.com (www.robertrudelic.com)|23.229.205.103|:443... connected. Created socket 6. Releasing 0x7f8a2b903950 (new refcount 1). Initiating SSL handshake. Handshake successful; connected socket 6 to SSL handle 0x7f8a2b9040f0 certificate: subject: CN=robertrudelic.com,OU=Domain Control Validated issuer: CN=Go Daddy Secure Certificate Authority - G2,OU=http://certs.godaddy.com/repository/,O=GoDaddy.com\\, Inc.,L=Scottsdale,ST=Arizona,C=US X509 certificate successfully verified and matches host www.robertrudelic.com ---request begin--- GET /wp-admin/options-general.php?page=exelana_kick_start_cart_settings_page =exksc_tab_products HTTP/1.1 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.77 Safari/537.36 Accept: */* Accept-Encoding: identity Host: www.robertrudelic.com Connection: Keep-Alive ---request end--- HTTP request sent, awaiting response... ---response begin--- HTTP/1.1 200 OK Date: Tue, 20 Nov 2018 18:57:23 GMT Server: Apache X-Powered-By: PHP/7.2.6 Expires: Wed, 11 Jan 1984 05:00:00 GMT Cache-Control: no-cache, must-revalidate, max-age=0 X-Frame-Options: SAMEORIGIN Referrer-Policy: strict-origin-when-cross-origin Vary: Accept-Encoding,User-Agent Keep-Alive: timeout=5 Connection: Keep-Alive Transfer-Encoding: chunked Content-Type: text/html; charset=UTF-8 ---response end--- HTTP/1.1 200 OK Date: Tue, 20 Nov 2018 18:57:23 GMT Server: Apache X-Powered-By: PHP/7.2.6 Expires: Wed, 11 Jan 1984 05:00:00 GMT Cache-Control: no-cache, must-revalidate, max-age=0 X-Frame-Options: SAMEORIGIN Referrer-Policy: strict-origin-when-cross-origin Vary: Accept-Encoding,User-Agent Keep-Alive: timeout=5 Connection: Keep-Alive Transfer-Encoding: chunked Content-Type: text/html; charset=UTF-8 Registered socket 6 for persistent reuse. URI content encoding = 'UTF-8' Length: unspecified [text/html] Saving to: 'tab_products.html' tab_products.html[<=> ] 939.82K 923KB/sin 1.0s Disabling further reuse of socket 6. Closed 6/SSL 0x7f8a2b9040f0 2018-11-20 10:57:29 (923 KB/s) - Read error at byte 962378 (Success).Giving up. -Original Message- From: Dale R. Worley [mailto:wor...@alum.mit.edu] Sent: Tuesday, November 20, 2018 7:30 AM To: Tony Lewis Cc: bug-wget@gnu.org Subject: Re: [Bug-wget] Read error (Success)? "Tony Lewis" writes: > I'm getting the following error and don't understand what it's trying to > tell me: > > Read error at byte 97430 (Success) > > What could the server be doing to cause wget to report an error with the > details being "Success"? My guess is that the server's response starts with a message including the description "Success". > For what it's worth, the page in question is coming from WordPress and the > PHP script that's generating the page did in fact emit 97430 bytes of data. > Could the server be leaving the port in some weird state? An easy way to help us is to report exactly the wget command line you used, so we can replicate what you did and see what happens. (As opposed to now, when we're stuck making guesses as to what might have happened.) Dale
Re: [Bug-wget] Read error (Success)?
"Tony Lewis" writes: > I'm getting the following error and don't understand what it's trying to > tell me: > > Read error at byte 97430 (Success) > > What could the server be doing to cause wget to report an error with the > details being "Success"? My guess is that the server's response starts with a message including the description "Success". > For what it's worth, the page in question is coming from WordPress and the > PHP script that's generating the page did in fact emit 97430 bytes of data. > Could the server be leaving the port in some weird state? An easy way to help us is to report exactly the wget command line you used, so we can replicate what you did and see what happens. (As opposed to now, when we're stuck making guesses as to what might have happened.) Dale
[Bug-wget] Read error (Success)?
I'm getting the following error and don't understand what it's trying to tell me: Read error at byte 97430 (Success) What could the server be doing to cause wget to report an error with the details being "Success"? For what it's worth, the page in question is coming from WordPress and the PHP script that's generating the page did in fact emit 97430 bytes of data. Could the server be leaving the port in some weird state? Thanks in advance! Tony
[Bug-wget] Should wget -qO- be used? (when "Read error at byte 2416640 (Success).Retrying." is seen)
Hi, I see the message like "Read error at byte 2416640 (Success).Retrying." when I use `wget -qO- url`. I am wondering whether stdout should be use as an output file when an error like this may occur. When an error occur, will wget sometimes rewind the output file a bit (in this case, the output should not be a pipe)? -- Regards, Peng
[Bug-wget] [bug #45792] wget: Read error in TLS connection with openssl s_server -www server
URL: http://savannah.gnu.org/bugs/?45792 Summary: wget: Read error in TLS connection with openssl s_server -www server Project: GNU Wget Submitted by: nok Submitted on: Di 18 Aug 2015 13:19:01 CEST Category: Protocol Issue Severity: 3 - Normal Priority: 5 - Normal Status: None Privacy: Public Assigned to: None Originator Name: Originator Email: Open/Closed: Open Discussion Lock: Any Release: 1.16.3 Operating System: None Reproducibility: None Fixed Release: None Planned Release: None Regression: None Work Required: None Patch Included: None ___ Details: Hello, --8-- What I set up a test server with: openssl s_server -CAfile ... -key ... -cert ... -www and try wget with it, I get errors: --2015-08-18 12:29:07-- https://www.vinc17.net:4433/ Resolving www.vinc17.net (www.vinc17.net)... 92.243.22.117, 2001:4b98:dc0:45:216:3eff:fe9b:eb2f Connecting to www.vinc17.net (www.vinc17.net)|92.243.22.117|:4433... connected. HTTP request sent, awaiting response... 200 ok Length: unspecified [text/html] Saving to: ‘index.html’ index.html [ = ] 5.26K --.-KB/s in 0s 2015-08-18 12:29:07 (204 MB/s) - Read error at byte 5386 (The TLS connection was non-properly terminated.).Retrying. --2015-08-18 12:29:08-- (try: 2) https://www.vinc17.net:4433/ Connecting to www.vinc17.net (www.vinc17.net)|92.243.22.117|:4433... connected. HTTP request sent, awaiting response... 200 ok Length: unspecified [text/html] Saving to: ‘index.html’ index.html [ = ] 5.26K --.-KB/s in 0s 2015-08-18 12:29:08 (1.21 GB/s) - Read error at byte 5386 (The TLS connection was non-properly terminated.).Retrying. ... --8-- https://bugs.debian.org/744170 thxregards Noël ___ Reply to this item at: http://savannah.gnu.org/bugs/?45792 ___ Nachricht gesendet von/durch Savannah http://savannah.gnu.org/
Re: [Bug-wget] Read error at byte ...
On Wednesday 19 March 2014 15:27:04 Jeffrey Walton wrote: On Wed, Mar 19, 2014 at 3:18 PM, Ángel González keis...@gmail.com wrote: On 19/03/14 12:52, Tim Ruehsen wrote: On Tuesday 18 March 2014 20:05:07 Daniel Kahn Gillmor wrote: On 03/18/2014 05:31 PM, Tim Rühsen wrote: $ wget -d --ca-certificate=ca-rsa-cert.pem --private-key=ca-rsa-key-plain.pem https://example.com:8443 2014-03-18 21:48:04 (1.88 GB/s) - Read error at byte 5116 (The TLS connection was non-properly terminated.).Retrying. There seems to be a problem in Wget 1.15 (on Debian SID)... ... In our case, the connection shutdown by the server generates an error at the Wget side. (I guess this is a difference between SSL and plain TCP connections.) Wget assumes the transfer being incomplete and tries it again and again. Not really a bug, but also not the result a user would expect... Saying the server is buggy doesn't help either. In order to close a ssl session, the server should send a close_notify message, which seems to be what the server is not doing (in addition of not providing the Content-Length). IIS is a well-known server not doing it: https://bugs.php.net/bug.php?id=23220 That's actually OpenSSL's s_server (unless Tim's tests were carried out with a different platform). I took the example OpenSSL server invocation from your original post: $ openssl s_server -accept 8443 -www -certform PEM -cert server-rsa-cert.pem - keyform PEM -key server-rsa-key-plain.pem -tls1 -cipher kRSA:HIGH:-EDH Tim
Re: [Bug-wget] Read error at byte ...
On Wed, Mar 19, 2014 at 3:18 PM, Ángel González keis...@gmail.com wrote: On 19/03/14 12:52, Tim Ruehsen wrote: On Tuesday 18 March 2014 20:05:07 Daniel Kahn Gillmor wrote: On 03/18/2014 05:31 PM, Tim Rühsen wrote: $ wget -d --ca-certificate=ca-rsa-cert.pem --private-key=ca-rsa-key-plain.pem https://example.com:8443 2014-03-18 21:48:04 (1.88 GB/s) - Read error at byte 5116 (The TLS connection was non-properly terminated.).Retrying. There seems to be a problem in Wget 1.15 (on Debian SID)... ... In our case, the connection shutdown by the server generates an error at the Wget side. (I guess this is a difference between SSL and plain TCP connections.) Wget assumes the transfer being incomplete and tries it again and again. Not really a bug, but also not the result a user would expect... Saying the server is buggy doesn't help either. In order to close a ssl session, the server should send a close_notify message, which seems to be what the server is not doing (in addition of not providing the Content-Length). IIS is a well-known server not doing it: https://bugs.php.net/bug.php?id=23220 That's actually OpenSSL's s_server (unless Tim's tests were carried out with a different platform). Jeff
Re: [Bug-wget] Connection closed vs read error
On 08/09/2012 12:42 AM, ptrk mj wrote: Greetings everyone, I'd like to know what is the technical difference between Connection closed at byte x. and Read error at byte x/y (Connection timed out). AIUI, Connection closed at byte x means that the remote end closed the connection while wget was still expecting to receive more data (as judged by Content-Length or the like). Note that in cases where the server doesn't tell us how much data to expect, you would never see this message, since in that case there's no way to know whether the server closed early, or if it closed because it was properly finished sending content. Read error at byte x/y (Connection timed out). means that we simply stopped receiving packets from the remote server (not even a connection-closing packet), and the connection eventually timed out. HTH, -mjc
Re: [Bug-wget] Connection closed vs read error
Thanks for sheding light on it. It's important to understand what's going on. ptrkmj On 8/9/12, Micah Cowan mi...@cowan.name wrote: On 08/09/2012 12:42 AM, ptrk mj wrote: Greetings everyone, I'd like to know what is the technical difference between Connection closed at byte x. and Read error at byte x/y (Connection timed out). AIUI, Connection closed at byte x means that the remote end closed the connection while wget was still expecting to receive more data (as judged by Content-Length or the like). Note that in cases where the server doesn't tell us how much data to expect, you would never see this message, since in that case there's no way to know whether the server closed early, or if it closed because it was properly finished sending content. Read error at byte x/y (Connection timed out). means that we simply stopped receiving packets from the remote server (not even a connection-closing packet), and the connection eventually timed out. HTH, -mjc
