LiteSpeed Support Forums - upload files problem

LiteSpeed Support Forums (http://www.litespeedtech.com/support/forum/index.php)

- Bug Reports (http://www.litespeedtech.com/support/forum/forumdisplay.php?f=9)

- - upload files problem (http://www.litespeedtech.com/support/forum/showthread.php?t=3568)

upload files problem

It happends sometimes: when i uploading files it don't finish request:

Code:

2009-12-07 12:10:26.923 [NOTICE] [127.0.0.1:58421-0#fdb.dev] Content len: 224961, Request line: 

POST /contents/upload?format=js&form_type=poster&form_id=1&random=0.8401927328668535 HTTP/1.1

2009-12-07 12:10:26.923 [DEBUG] [127.0.0.1:58421-0#fdb.dev] Read Request Body!

2009-12-07 12:10:26.923 [DEBUG] [127.0.0.1:58421-0#fdb.dev] Read from client: 7

2009-12-07 12:10:26.923 [DEBUG] [127.0.0.1:58421-0#fdb.dev] Finsh request body 1053/0 bytes!

2009-12-07 12:10:26.923 [DEBUG] [127.0.0.1:58421-0#fdb.dev] processNewReq() return 0. 

2009-12-07 12:10:27.824 [DEBUG] [127.0.0.1:58421-0#fdb.dev] HttpConnection::onReadEx(), state: 2!

2009-12-07 12:10:27.825 [DEBUG] [127.0.0.1:58421-0#fdb.dev] Read Request Body!

2009-12-07 12:10:27.825 [DEBUG] [127.0.0.1:58421-0#fdb.dev] Read from client: 0

2009-12-07 12:10:28.852 [DEBUG] [127.0.0.1:58421-0#fdb.dev] HttpConnection::onReadEx(), state: 2!

2009-12-07 12:10:28.852 [DEBUG] [127.0.0.1:58421-0#fdb.dev] Read Request Body!

2009-12-07 12:10:28.852 [DEBUG] [127.0.0.1:58421-0#fdb.dev] Read from client: 0

2009-12-07 12:10:29.853 [DEBUG] [127.0.0.1:58421-0#fdb.dev] HttpConnection::onReadEx(), state: 2!

2009-12-07 12:10:29.853 [DEBUG] [127.0.0.1:58421-0#fdb.dev] Read Request Body!

2009-12-07 12:10:29.853 [DEBUG] [127.0.0.1:58421-0#fdb.dev] Read from client: 0

2009-12-07 12:10:30.859 [DEBUG] [127.0.0.1:58421-0#fdb.dev] HttpConnection::onReadEx(), state: 2!

2009-12-07 12:10:30.859 [DEBUG] [127.0.0.1:58421-0#fdb.dev] Read Request Body!

2009-12-07 12:10:30.859 [DEBUG] [127.0.0.1:58421-0#fdb.dev] Read from client: 0

2009-12-07 12:10:31.860 [DEBUG] [127.0.0.1:58421-0#fdb.dev] HttpConnection::onReadEx(), state: 2!

2009-12-07 12:10:31.860 [DEBUG] [127.0.0.1:58421-0#fdb.dev] Read Request Body!

2009-12-07 12:10:31.860 [DEBUG] [127.0.0.1:58421-0#fdb.dev] Read from client: 0

2009-12-07 12:10:32.863 [DEBUG] [127.0.0.1:58421-0#fdb.dev] HttpConnection::onReadEx(), state: 2!

2009-12-07 12:10:32.863 [DEBUG] [127.0.0.1:58421-0#fdb.dev] Read Request Body!

2009-12-07 12:10:32.863 [DEBUG] [127.0.0.1:58421-0#fdb.dev] Read from client: 0

2009-12-07 12:10:33.864 [DEBUG] [127.0.0.1:58421-0#fdb.dev] HttpConnection::onReadEx(), state: 2!

2009-12-07 12:10:33.864 [DEBUG] [127.0.0.1:58421-0#fdb.dev] Read Request Body!

2009-12-07 12:10:33.864 [DEBUG] [127.0.0.1:58421-0#fdb.dev] Read from client: 0

2009-12-07 12:10:34.865 [DEBUG] [127.0.0.1:58421-0#fdb.dev] HttpConnection::onReadEx(), state: 2!

2009-12-07 12:10:34.865 [DEBUG] [127.0.0.1:58421-0#fdb.dev] Read Request Body!

2009-12-07 12:10:34.865 [DEBUG] [127.0.0.1:58421-0#fdb.dev] Read from client: 0

2009-12-07 12:10:35.866 [DEBUG] [127.0.0.1:58421-0#fdb.dev] HttpConnection::onReadEx(), state: 2!

2009-12-07 12:10:35.866 [DEBUG] [127.0.0.1:58421-0#fdb.dev] Read Request Body!

2009-12-07 12:10:35.867 [DEBUG] [127.0.0.1:58421-0#fdb.dev] Read from client: 0

2009-12-07 12:10:36.868 [DEBUG] [127.0.0.1:58421-0#fdb.dev] HttpConnection::onReadEx(), state: 2!

2009-12-07 12:10:36.868 [DEBUG] [127.0.0.1:58421-0#fdb.dev] Read Request Body!

2009-12-07 12:10:36.868 [DEBUG] [127.0.0.1:58421-0#fdb.dev] Read from client: 0

2009-12-07 12:10:37.869 [DEBUG] [127.0.0.1:58421-0#fdb.dev] HttpConnection::onReadEx(), state: 2!

2009-12-07 12:10:37.869 [DEBUG] [127.0.0.1:58421-0#fdb.dev] Read Request Body!

2009-12-07 12:10:37.869 [DEBUG] [127.0.0.1:58421-0#fdb.dev] Read from client: 0

2009-12-07 12:10:38.873 [DEBUG] [127.0.0.1:58421-0#fdb.dev] HttpConnection::onReadEx(), state: 2!

2009-12-07 12:10:38.873 [DEBUG] [127.0.0.1:58421-0#fdb.dev] Read Request Body!

2009-12-07 12:10:38.873 [DEBUG] [127.0.0.1:58421-0#fdb.dev] Read from client: 0

2009-12-07 12:10:39.874 [DEBUG] [127.0.0.1:58421-0#fdb.dev] HttpConnection::onReadEx(), state: 2!

2009-12-07 12:10:39.874 [DEBUG] [127.0.0.1:58421-0#fdb.dev] Read Request Body!

2009-12-07 12:10:39.874 [DEBUG] [127.0.0.1:58421-0#fdb.dev] Read from client: 0

2009-12-07 12:10:40.875 [DEBUG] [127.0.0.1:58421-0#fdb.dev] HttpConnection::onReadEx(), state: 2!

2009-12-07 12:10:40.875 [DEBUG] [127.0.0.1:58421-0#fdb.dev] Read Request Body!

2009-12-07 12:10:40.875 [DEBUG] [127.0.0.1:58421-0#fdb.dev] Read from client: 0

2009-12-07 12:10:41.876 [DEBUG] [127.0.0.1:58421-0#fdb.dev] HttpConnection::onReadEx(), state: 2!

2009-12-07 12:10:41.877 [DEBUG] [127.0.0.1:58421-0#fdb.dev] Read Request Body!

2009-12-07 12:10:41.877 [DEBUG] [127.0.0.1:58421-0#fdb.dev] Read from client: 0

2009-12-07 12:10:42.878 [DEBUG] [127.0.0.1:58421-0#fdb.dev] HttpConnection::onReadEx(), state: 2!

2009-12-07 12:10:42.878 [DEBUG] [127.0.0.1:58421-0#fdb.dev] Read Request Body!

2009-12-07 12:10:42.878 [DEBUG] [127.0.0.1:58421-0#fdb.dev] Read from client: 0

2009-12-07 12:10:43.879 [DEBUG] [127.0.0.1:58421-0#fdb.dev] HttpConnection::onReadEx(), state: 2!

2009-12-07 12:10:43.880 [DEBUG] [127.0.0.1:58421-0#fdb.dev] Read Request Body!

2009-12-07 12:10:43.880 [DEBUG] [127.0.0.1:58421-0#fdb.dev] Read from client: 0

2009-12-07 12:10:44.881 [DEBUG] [127.0.0.1:58421-0#fdb.dev] HttpConnection::onReadEx(), state: 2!

2009-12-07 12:10:44.881 [DEBUG] [127.0.0.1:58421-0#fdb.dev] Read Request Body!

2009-12-07 12:10:44.881 [DEBUG] [127.0.0.1:58421-0#fdb.dev] Read from client: 0

2009-12-07 12:10:45.882 [DEBUG] [127.0.0.1:58421-0#fdb.dev] HttpConnection::onReadEx(), state: 2!

2009-12-07 12:10:45.882 [DEBUG] [127.0.0.1:58421-0#fdb.dev] Read Request Body!

litespeed 4.0.11
safari 4 as webbrowser

when i use script/server (simple ruby web server for developing) it works ok.

Looks like LSWS has difficulty parsing "Content-length" from the POST request.
Do you have similar issue with other browsers?

Can provide a TCPDUMP or wireshark capture of the request header and body?
tcpdump -s0 -X -i lo port <your_lsws_port>

wireshark is for windows.

Not sure why it sent POST twice via two connections.
The request itself looks normal.

in the debug log, does it ever show something like

Finsh request body xxxx/227232 bytes

I think that i know answer.

I was using observer on form (on submit).
2 request was probably reason why it works so bad. 1 request goes to iframe (ajax request can't send file fields) and second was by my mistake send by ajax.

No i fixed that and i hope it will resolve my problem with uploading.

hmm removing observer(onsubmit) don't change to mutch.

Quote:

root@core2:~# tcpdump -s0 -X -i em0 src 89.79.255.101 and dst port 80
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on em0, link-type EN10MB (Ethernet), capture size 65535 bytes
01:40:23.247309 IP chello089079255101.chello.pl.54077 > core2.xan.pl.http: P 4259178209:4259179483(1274) ack 2386399683 win 33304 <nop,nop,timestamp 420775690 2743776159>
0x0000: 4500 052e b90d 4000 3506 5cde 594f ff65 E.....@.5.\.YO.e
0x0010: 5b79 76b0 d33d 0050 fddd e6e1 8e3d 91c3 [yv..=.P.....=..
0x0020: 8018 8218 35a5 0000 0101 080a 1914 870a ....5...........
0x0030: a38a b39f 504f 5354 202f 636f 6e74 656e ....POST./conten
0x0040: 7473 2f75 706c 6f61 643f 666f 726d 6174 ts/upload?format
0x0050: 3d6a 7326 666f 726d 5f74 7970 653d 706f =js&form_type=po
0x0060: 7374 6572 2666 6f72 6d5f 6964 3d31 2672 ster&form_id=1&r
0x0070: 616e 646f 6d3d 302e 3339 3138 3531 3132 andom=0.39185112
0x0080: 3532 3835 3032 3934 2048 5454 502f 312e 52850294.HTTP/1.
0x0090: 310d 0a48 6f73 743a 2066 6462 2e70 6c0d 1..Host:.fdb.pl.
0x00a0: 0a52 6566 6572 6572 3a20 6874 7470 3a2f .Referer:.http:/
0x00b0: 2f66 6462 2e70 6c2f 636f 6e74 656e 7473 /fdb.pl/contents
0x00c0: 2f61 6464 2f6d 6f76 6965 2f31 0d0a 436f /add/movie/1..Co
0x00d0: 6e74 656e 742d 5479 7065 3a20 6d75 6c74 ntent-Type:.mult
0x00e0: 6970 6172 742f 666f 726d 2d64 6174 613b ipart/form-data;
0x00f0: 2062 6f75 6e64 6172 793d 2d2d 2d2d 5765 .boundary=----We
0x0100: 624b 6974 466f 726d 426f 756e 6461 7279 bKitFormBoundary
0x0110: 4e47 6141 4a6d 7945 6b33 3531 3365 7171 NGaAJmyEk3513eqq
0x0120: 0d0a 4f72 6967 696e 3a20 6874 7470 3a2f ..Origin:.http:/
0x0130: 2f66 6462 2e70 6c0d 0a41 6363 6570 743a /fdb.pl..Accept:
0x0140: 2061 7070 6c69 6361 7469 6f6e 2f78 6d6c .application/xml
0x0150: 2c61 7070 6c69 6361 7469 6f6e 2f78 6874 ,application/xht
0x0160: 6d6c 2b78 6d6c 2c74 6578 742f 6874 6d6c ml+xml,text/html
0x0170: 3b71 3d30 2e39 2c74 6578 742f 706c 6169 ;q=0.9,text/plai
0x0180: 6e3b 713d 302e 382c 696d 6167 652f 706e n;q=0.8,image/pn
0x0190: 672c 2a2f 2a3b 713d 302e 350d 0a43 6f6e g,*/*;q=0.5..Con
0x01a0: 7465 6e74 2d4c 656e 6774 683a 2032 3237 tent-Length:.227
0x01b0: 3233 320d 0a55 7365 722d 4167 656e 743a 232..User-Agent:
0x01c0: 204d 6f7a 696c 6c61 2f35 2e30 2028 4d61 .Mozilla/5.0.(Ma
0x01d0: 6369 6e74 6f73 683b 2055 3b20 496e 7465 cintosh;.U;.Inte
0x01e0: 6c20 4d61 6320 4f53 2058 2031 305f 365f l.Mac.OS.X.10_6_
0x01f0: 323b 2070 6c2d 706c 2920 4170 706c 6557 2;.pl-pl).AppleW
0x0200: 6562 4b69 742f 3533 312e 3231 2e38 2028 ebKit/531.21.8.(
0x0210: 4b48 544d 4c2c 206c 696b 6520 4765 636b KHTML,.like.Geck
0x0220: 6f29 2056 6572 7369 6f6e 2f34 2e30 2e34 o).Version/4.0.4
0x0230: 2053 6166 6172 692f 3533 312e 3231 2e31 .Safari/531.21.1
0x0240: 300d 0a41 6363 6570 742d 4c61 6e67 7561 0..Accept-Langua
0x0250: 6765 3a20 706c 2d70 6c0d 0a41 6363 6570 ge:.pl-pl..Accep
0x0260: 742d 456e 636f 6469 6e67 3a20 677a 6970 t-Encoding:.gzip
0x0270: 2c20 6465 666c 6174 650d 0a43 6f6f 6b69 ,.deflate..Cooki
0x0280: 653a 205f 5f75 746d 613d 3739 3034 3435 e:.__utma=790445
0x0290: 3437 2e31 3035 3936 3736 3732 362e 3132 47.1059676726.12
0x02a0: 3630 3233 3233 3031 2e31 3236 3032 3332 60232301.1260232
0x02b0: 3330 312e 3132 3630 3233 3233 3031 2e31 301.1260232301.1
0x02c0: 3b20 5f5f 7574 6d62 3d37 3930 3434 3534 ;.__utmb=7904454
0x02d0: 372e 372e 3130 2e31 3236 3032 3332 3330 7.7.10.126023230
0x02e0: 313b 205f 5f75 746d 633d 3739 3034 3435 1;.__utmc=790445
0x02f0: 3437 3b20 5f5f 7574 6d7a 3d37 3930 3434 47;.__utmz=79044
0x0300: 3534 372e 3132 3630 3233 3233 3031 2e31 547.1260232301.1
0x0310: 2e31 2e75 746d 6373 723d 2864 6972 6563 .1.utmcsr=(direc
0x0320: 7429 7c75 746d 6363 6e3d 2864 6972 6563 t)|utmccn=(direc
0x0330: 7429 7c75 746d 636d 643d 286e 6f6e 6529 t)|utmcmd=(none)
0x0340: 3b20 6664 6253 6573 7369 6f6e 3d42 4168 ;.fdbSession=BAh
0x0350: 3743 6a6f 5158 324e 7a63 6d5a 6664 4739 7CjoQX2NzcmZfdG9
0x0360: 725a 5734 694d 5745 794d 3068 5764 5452 rZW4iMWEyM0hWdTR
0x0370: 7464 564e 3163 7a63 7952 544e 7653 7974 tdVN1czcyRTNvSyt
0x0380: 4d4e 4852 465a 6c5a 6d51 7a51 3365 446b MNHRFZlZmQzQ3eDk
0x0390: 3151 6b6c 4a5a 304a 5965 5446 3354 4655 1QklJZ0JYeTF3TFU
0x03a0: 394f 6731 7759 584e 7a64 3239 795a 4349 9Og1wYXNzd29yZCI
0x03b0: 744d 6a52 694f 446b 774e 6a51 7a4d 324a tMjRiODkwNjQzM2J
0x03c0: 694d 3259 3059 574d 3259 3256 694e 324a iM2Y0YWM2Y2ViN2J
0x03d0: 6d4d 4442 6d59 7a42 6c4d 7a49 784d 4467 mMDBmYzBlMzIxMDg
0x03e0: 774e 4749 304d 7a6f 5063 3256 7a63 326c wNGI0MzoPc2Vzc2l
0x03f0: 7662 6c39 705a 4349 6c59 324a 6b59 7a63 vbl9pZCIlY2JkYzc
0x0400: 354f 575a 694d 5759 354f 4456 6c4e 6a46 5OWZiMWY5ODVlNjF
0x0410: 694e 4468 6b5a 5463 354e 544d 324e 7a63 iNDhkZTc5NTM2Nzc
0x0420: 784d 5459 3644 4856 7a5a 584a 6661 5752 xMTY6DHVzZXJfaWR
0x0430: 7042 6a6f 4c63 3256 6a64 584a 6c56 4125 pBjoLc2VjdXJlVA%
0x0440: 3344 2533 442d 2d37 6233 6366 3061 3834 3D%3D--7b3cf0a84
0x0450: 3536 3637 6266 3238 3136 3836 6138 3131 5667bf281686a811
0x0460: 3764 3762 6136 6432 6433 6661 3862 613b 7d7ba6d2d3fa8ba;
0x0470: 2070 6173 7377 6f72 643d 6264 3661 6435 .password=bd6ad5
0x0480: 3738 6232 3038 3739 6461 3564 3030 3465 78b20879da5d004e
0x0490: 3535 6331 6264 6437 3361 3233 6237 3865 55c1bdd73a23b78e
0x04a0: 3835 3b20 7273 695f 7365 6773 3d41 3039 85;.rsi_segs=A09
0x04b0: 3739 385f 3130 3036 367c 4130 3937 3938 798_10066|A09798
0x04c0: 5f31 3030 3031 7c41 3039 3739 385f 3130 _10001|A09798_10
0x04d0: 3030 327c 4130 3937 3938 5f31 3030 3133 002|A09798_10013
0x04e0: 7c41 3039 3739 385f 3130 3034 327c 4130 |A09798_10042|A0
0x04f0: 3937 3938 5f31 3030 3435 7c41 3039 3739 9798_10045|A0979
0x0500: 385f 3130 3035 303b 2075 7365 725f 6964 8_10050;.user_id
0x0510: 3d31 0d0a 436f 6e6e 6563 7469 6f6e 3a20 =1..Connection:.
0x0520: 6b65 6570 2d61 6c69 7665 0d0a 0d0a keep-alive....

With keep-alive it don't works but without is ok. How it is possible?
i set bigger timeout for keep-alive maby this will help.

OK, we will do more test on this.

Can you please send us the full debug log for two consecutive keepalive requests, and the second the request is hanging?

well, I tried the Safari 4.0.2 and 4.0.4 on a MacBook, it wont able to do consecutive POST on a keepalive connection. It crashes when sends the second request.:eek:

More likely a bug in Safari. The solution is to turn off keepalive when detect POST request from Safari. Will add a feature in 4.0.12 to turn off keepalive with rewrite rule when "nokeepalive" environment is set.