[bug #61038] Windows post fails to post files over 65536 bytes,

[anonymous]

Follow-up Comment #9, bug #61038 (project wget):

I got the broken binaries from the only place available:

https://eternallybored.org/misc/wget/1.21.4/32/wget.exe

There is a new version:

https://github.com/rockdaboot/wget2/releases/download/v2.1.0/wget2.exe

2'386'432, "stripped", UPX:ed

unfortunately only 64-bit. Not YET tested.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #61038] Windows post fails to post files over 65536 bytes,

[Ozhan Duz]

Follow-up Comment #8, bug #61038 (project wget):

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)
___

Additional Item Attachment:

File name: wget-file-upload-test-capture.pcapng.gz Size:16 KB
   




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #61038] Windows post fails to post files over 65536 bytes,

[Tim Ruehsen]

Follow-up Comment #7, bug #61038 (project wget):

On the first glimpse, https://github.com/rockdaboot/wget2/issues/256 is
unrelated.

But then it seems that the poll/select function on Windows sometimes reports
"ready to read" but the next read returns 0 bytes read. (Wget2 used
non-blocking I/O).

Wget uses blocking I/O - but that doesn't matter. I assume that a read also
sometimes reports 0 bytes.

Now this issue is about POST, so mainly write() functionality. I *assume* we
might see the same or similar thing here as well, that write()/send() returns
0 and wget stops.

I never saw this behavior on native Linux nor with Wine emulation.
Also, testing on my wife's Win11 laptop never showed this behavior.

The aforementioned GH issue 256 contains two links to a statically wget2
binary. Please feel free to test with these binaries in order to reproduce the
issue and report on that bug if possible.
More information may lead to a fix in gnulib which also affects wget1.x (just
needs a recompilation then).


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #61038] Windows post fails to post files over 65536 bytes,

[anonymous]

Follow-up Comment #6, bug #61038 (project wget):

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 .

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #61038] Windows post fails to post files over 65536 bytes,

[Darshit Shah]

Follow-up Comment #5, bug #61038 (project wget):

Unfortunately, I am unable to reproduce this on Linux.

This seems to be a Windows only issue. Could you please mention where you got
your Windows binaries from? Maybe raise an issue with them about it as well.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #61038] Windows post fails to post files over 65536 bytes,

[anonymous]

Follow-up Comment #4, bug #61038 (project wget):

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

To   : bug-wget@gnu.org
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 )
> or to our mailing list .
> Visit  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.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #61038] Windows post fails to post files over 65536 bytes,

[anonymous]

Follow-up Comment #3, bug #61038 (project wget):

Already reported. Same bug as here:
https://lists.gnu.org/archive/html/bug-wget/2021-08/msg2.html

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

Re: [bug #61038] Windows post fails to post files over 65536 bytes,

[Taylor]

> Follow-up Comment #2, bug #61038 (project wget):
> Since this is a Windows issue, could you please report this issue to where you
> got the binary from ?

See also: https://lists.gnu.org/archive/html/bug-wget/2021-08/msg2.html

It reliably fails already above 8 KiO.

[bug #61038] Windows post fails to post files over 65536 bytes,

[Tim Ruehsen]

Follow-up Comment #2, bug #61038 (project wget):

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.


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #61038] Windows post fails to post files over 65536 bytes,

[anonymous]

Follow-up Comment #1, bug #61038 (project wget):

Confirmed this bug does not exist on a mac with version 1.20 It is a windows
only issue.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #61038] Windows post fails to post files over 65536 bytes,

[anonymous]

URL:
  

 Summary: Windows post fails to post files over 65536 bytes,
 Project: GNU Wget
Submitted by: None
Submitted on: Fri 13 Aug 2021 08:54:25 PM UTC
Category: Program Logic
Severity: 3 - Normal
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: Paul Breed
Originator Email: p...@rasdoc.com
 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:


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.








___

File Attachments:


---
Date: Fri 13 Aug 2021 08:54:25 PM UTC  Name: Works_Log_1P11.txt  Size: 1001B  
By: None


---
Date: Fri 13 Aug 2021 08:54:25 PM UTC  Name: Fails_Log_1P20.txt  Size: 3KiB  
By: None



___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/