#2587 closed defect (fixed)
can't peek at some http traffic
Reported by: | Antoine Martin | Owned by: | Antoine Martin |
---|---|---|---|
Priority: | critical | Milestone: | 4.1 |
Component: | html5 | Version: | 3.0.x |
Keywords: | Cc: |
Description
Fedora 31 server running trunk (v4).
Instead of detecting the http traffic, peek returns no data and we fail with:
io_in_cb(<socket.socket fd=4, family=AddressFamily.AF_INET, type=SocketKind.SOCK_STREAM, proto=0, laddr=('0.0.0.0', 10000)>, <flags G_IO_IN of type GLib.IOCondition>) (..) socket tcp socket: 192.168.0.10:10000 <- 192.168.0.106:47438 peek: got 0 bytes may_wrap_socket: no data, not wrapping (..) New tcp connection received from '192.168.0.106:47438' on '0.0.0.0:10000'
That's despite waiting for 1 second polling the socket...
wireshark shows that the TCP packet does contain the HTTP GET request:
GET / HTTP/1.1 Host: 192.168.0.10:10000 Connection: keep-alive Cache-Control: max-age=0 Upgrade-Insecure-Requests: 1 Save-Data: on User-Agent: Mozilla/5.0 (Linux; Android 10; PH-1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.87 Mobile Safari/537.36 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9 Accept-Encoding: gzip, deflate Accept-Language: en-GB,en;q=0.9,fr-FR;q=0.8,fr;q=0.7,th-TH;q=0.6,th;q=0.5,en-US;q=0.4
This happens with android clients, but not with desktop browsers!?
Attachments (3)
Change History (10)
comment:1 Changed 14 months ago by
Status: | new → assigned |
---|
comment:2 Changed 14 months ago by
This is a kernel / distro bug.
Every other distro works just fine. Tested: Ubuntu 18.04, Ubuntu 19.10, Debian Stretch, Debian Buster, etc..
The problem only occurs on Fedora 30 and 31. (Not tested Fedora 29 or earlier).
And also with MS Windows servers!
comment:3 Changed 14 months ago by
Things I've tried:
- disabling and forcing nodelay / cork
- increasing the peek timeout
- different router, different network interface
Wireshark shows:
- client -> server: SYN
- server -> client: SYN+ACK
- client -> server: "GET /"
- server -> client: RST
...
Why do we reset the connection!? We're actually doing a recv when that happens!?
Also happens with v3.
comment:4 Changed 14 months ago by
The patch above uses the same workaround that is used with ssl sockets: emulate peek by actually reading from the socket (without PEEK) but cache the data and return it later.
Does not always help. No idea why.
comment:5 Changed 11 months ago by
Milestone: | 4.0 → 4.1 |
---|
comment:6 Changed 6 months ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
comment:7 Changed 3 months ago by
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/2587
Adding a
recv
call immediately after the empty peek shows that the data is there waiting to be read!?