Hi,

I successfully reproduce the problem with wget 1.21.2 on Windows which is build with gcc/mingw 9.3

I wrote a simple server app that accepts post data and return HTTP 200 if expected file size equals to actual one and return 400 if somethings goes wrong.

I tested the app on two different Window 10 desktop PC and works without error even for 1GB file uploads.

Then I published the app to a GitHub and test the app on GitHub Actions and tests failed after 16KB. wget uploads 16KB successfully but failed after 20th try for 256KB file.

Please see the logs from this url: https://github.com/webfolderio/wget-file-upload-test/runs/5012162406?check_suite_focus=true

I the tested server app on a public VPS and executed the tests and faced with the same results similar to GitHub actions test.

Similar to GitHub actions, wget fails to upload 256KB file after lots of try.

I attached the Wireshark capture data for the VPS test.
Hope that it helps to find the bug.

reference wget executable for tests: https://github.com/webfolderio/wget-windows

test scenarios:
localhost (wget) - localhost (server) - DESKTOP - OK
localhost (wget) - localhost (server) - GitHub Actions - 256KB FAILED
localhost (wget) - 0.0.0.0 (server)   - VPS Server - 256KB FAILED


(file #52783)

https://eternallybored.org/misc/wget

https://eternallybored.org/misc/wget/releases/wget-1.19.4-win32.zip

I tested many binaries from there and all are broken, most notably 1.19.4 and 1.21.1 , and IIRC also some older 1.17.xx and 1.15.xx .

1.21.2 is out ... and 2.0.0 out ... and reported to be broken. :-(

To   : -email is unavailable-
Subj : BUG in recent versions of WGET with POSTing more than 8 KiO data

> You are welcome to submit bug reports via the GNU Wget bug
> tracker (see <https://savannah.gnu.org/bugs/?func=additem&group=wget>)
> or to our mailing list <bug-wget@gnu.org>.
> Visit <https://lists.gnu.org/mailman/listinfo/bug-wget> to get
> more info (how to subscribe, list archives, ...).

There is (most likely) a severe bug in recent versions of WGET,
including 1.19.4 and 1.21.1, but not in good old 1.11.4 from
year 2008.

Expected behaviour: POSTing will work irrespective size of the postdata

Observed behaviour: POSTing fails with exit code 4 if size of the
                    postdata exceeds ca 8 KiO

With WGET 1.11.4 I could POST data irrespective size, only
percent-encoding tested at that time.

With CURL I can POST data irrespective size, both percent-encoded
and multipart-encoded.

With WGET 1.19.4 and 1.21.1 I can post data of limited size, both
percent-encoded and multipart-encoded.

With WGET 1.19.4 and 1.21.1 posting reliably fails if size of the
postdata exceeds ca 8 KiO.

I do the encoding myself and run WGET and CURL in a pretty raw way,
not caring about the fact that CURL can multipart-encode whereas
WGET can't.

Using the Win32 versions of WGET, Linux not installed.

Result from "--debug" success (exitcode is 0 and data arrives
at the server):

> ---request end---
> [writing BODY file YPOST.TMP ... done]
> HTTP request sent, awaiting response... seconds 60.00, Winsock error: 0
> seconds 60.00, Winsock error: 0
> seconds 60.00, Winsock error: 0

> ---response begin---
> HTTP/1.1 200 OK

Result from "--debug" failure (exitcode is 4 after 3 attempts
and data does not arrive at the server):

> ---request end---
> [writing BODY file YPOST.TMP ... Closed 4/SSL 0x009fb810
> Giving up.

> Saving cookies to YCOOK.TMP.
> Done saving cookies.

The report is not very verbose, "Closed" is the only hint about the
problem. The file YPOST.TMP contains the postdata and is good in
both cases, but bigger in the lower one.

Of course I can use CURL instead of WGET, but it's good to have
options, and bad to have bugs, given that this probably is a bug
of WGET. I am aware that CURL is more intended for posting than WGET,
but this used to work with old versions (1.11.4) before they got
unusable due to 3rd party hard cryptographic deprecation.

Since this is a Windows issue, could you please report this issue to where you got the binary from ?

Please feel free to update this issue with any information you get from there.

If you post a file > 65K the system sends (Size % 65K) of the file then closes the socket.

Version 1.11 works correctly. I've tried 1.19,1.20 and 1.21 and all three fail.

I've attached  --debug logs of working 1.11 and failing 1.20

Exact command line:

wget --post-file=obj\Release\SimpleHtml.bin 10.1.1.68:20034/appupdate.htm


I created a simple post target that doe snothing on the target.
And tried sending files of various sizes and any file < 16bits works and any file > 16 bits fails.

Have not yet tested oin Linux and Mac, suspect the issue is probably in the windows networking adapter layer.

Can also send pcaps of these failures if you want them.