Hi,
On Tue, May 09, Willy Tarreau wrote:
> On Tue, May 09, 2017 at 02:54:45PM +0300, Jarno Huuskonen wrote:
> > My firefox(52.1 on linux) was able to send 128k file,
> > but 800k file results in connection reset. My chrome sent 16k file, but
> > fails (ERR_CONNECTION_RESET) on 17k file (few times even the 17k file
> > worked).
>
> Hmmm that sounds bad, it looks like we've broken something again.
If it's haproxy error, then it's probably pretty old one. I'm getting
chrome(ERR_CONNECTION_RESET) errors with 1.5dev18, 1.5.2, 1.5.18 ...
> What status code are you facing there ? I remember we've had such
chrome ERR_CONNECTION_RESET (sending 2M file):
haproxy[22170]: 127.0.0.1:53466 [10/May/2017:10:54:15.427] test test/<NOSRV>
0/-1/-1/-1/1 302 122 - - LR-- 0/0/0/0/0 0/0 "POST /invalid HTTP/1.1"
chrome ok (sending 15k file):
haproxy[22170]: 127.0.0.1:53526 [10/May/2017:10:58:19.415] test test/<NOSRV>
0/-1/-1/-1/0 302 122 - - LR-- 0/0/0/0/0 0/0 "POST /invalid HTTP/1.1"
haproxy[22170]: 127.0.0.1:33674 [10/May/2017:10:58:19.423] test~ test/<NOSRV>
-1/-1/-1/-1/4 400 187 - - CR-- 1/1/0/0/0 0/0 "<BADREQ>"
haproxy[22170]: 127.0.0.1:33676 [10/May/2017:10:58:19.424] test~ test/<NOSRV>
-1/-1/-1/-1/4 400 187 - - CR-- 0/0/0/0/0 0/0 "<BADREQ>"
haproxy[22170]: 127.0.0.1:33678 [10/May/2017:10:58:19.430] test~ test/<NOSRV>
-1/-1/-1/-1/2 400 187 - - CR-- 0/0/0/0/0 0/0 "<BADREQ>"
haproxy[22170]: 127.0.0.1:33680 [10/May/2017:10:58:19.434] test~ test_be/wp1
0/0/3/2/5 404 429 - - ---- 1/1/0/0/0 0/0 "GET /invalid HTTP/1.1"
(the backend doesn't have /invalid -> so 404).
(the 400 BADREQ are chrome pre-connect (I think) they disappear with
option http-ignore-probes).
chrome ok (sending 17k file) (and option http-ignore-probes). Most of
the time sending 17k fails:
haproxy[22541]: 127.0.0.1:53630 [10/May/2017:11:04:03.022] test test/<NOSRV>
0/-1/-1/-1/0 302 122 - - LR-- 0/0/0/0/0 0/0 "POST /invalid HTTP/1.1"
haproxy[22541]: 127.0.0.1:33784 [10/May/2017:11:04:03.041] test~ test_be/wp1
0/0/3/1/5 404 429 - - ---- 1/1/0/0/0 0/0 "GET /invalid HTTP/1.1"
> an issue in the past where the server timeout could expire during
> a long upload because it was not being refreshed during the upload
> (it would thus result in a 504).
My test config:
global
log /dev/log local2 info
stats socket /tmp/stats level admin
defaults
mode http
log global
option httplog
retries 2
timeout queue 2s
timeout connect 1500ms
timeout client 30s
timeout server 30s
timeout http-keep-alive 4s
timeout http-request 3500ms
timeout check 1700ms
timeout tarpit 3s
frontend test
option http-ignore-probes
bind ipv4@127.0.0.1:80
bind ipv4@127.0.0.1:443 ssl crt ./crt.pem
acl is_plain dst_port 80
redirect scheme https code 302 if is_plain #!METH_POST
default_backend test_be
backend test_be
acl is_plain dst_port 80
server dummy1 some.apache.server.ip:443 ssl verify none
This is the html form I'm testing with:
<!DOCTYPE html>
<html>
<body>
<form action="http://127.0.0.1/invalid"; method="post"
enctype="multipart/form-data">
Select image to upload:
<input type="file" name="fileToUpload" id="fileToUpload">
<input type="submit" value="Upload Image" name="submit">
</form>
</body>
</html>
-Jarno
--
Jarno Huuskonen
