I observed this with a binary file of size: 26278368 bytes ... When I threw this particular HTTP Request: GET /Image.sub HTTP/1.1 Host: localhost Accept: */* Referer: http://localhost/crap User-Agent: Mozilla/4.0 (compatible; MSIE 5.00; Windows 98) Range: bytes=26276541- Pragma: no-cache Cache-Control: no-cache Connection: close i.e. last 1827 bytes or so, Tomcat failed to send _ANY_ data... However, it worked with a larger range of bytes before the end (say: 26000000-) or so.. I tried testing the same file, with the same request on HTTPD 2.0.55 ... It worked just fine, and gave me the last few bytes. Hence, I am reporting this as a bug. Please look into it.
Are you using the HTTP APR connector ?
(In reply to comment #1) > Are you using the HTTP APR connector ? Yes. (the statically compiled tcnative-1)
I can already tell you that telnet as a client on localhost has issues on Windows when doing sendfile (for whatever reasons, sendfile doesn't like it, and returns an error code). I don't think this is a bug in Tomcat.
(In reply to comment #3) > I can already tell you that telnet as a client on localhost has issues on > Windows when doing sendfile (for whatever reasons, sendfile doesn't like it, and > returns an error code). I don't think this is a bug in Tomcat. It's not about telnet ... it didn't work on my usual file-downloading client ... and oh, it DID work with telnet and my client with the 26000000- range. It's not a problem with telnet or sendfile as such... I suspect something more.
(In reply to comment #4) > It's not about telnet ... it didn't work on my usual file-downloading client ... > and oh, it DID work with telnet and my client with the 26000000- range. It's not > a problem with telnet or sendfile as such... I suspect something more. You can suspect all you want, I'll be looking at facts. So far, it seems to be going to WONTFIX land.
(In reply to comment #5) > (In reply to comment #4) > > It's not about telnet ... it didn't work on my usual file-downloading client ... > > and oh, it DID work with telnet and my client with the 26000000- range. It's not > > a problem with telnet or sendfile as such... I suspect something more. > > You can suspect all you want, I'll be looking at facts. So far, it seems to be > going to WONTFIX land. Fine. Put up with it and stay with Non-HTTP-Compliant Land :P
(In reply to comment #5) > (In reply to comment #4) > > It's not about telnet ... it didn't work on my usual file-downloading client ... > > and oh, it DID work with telnet and my client with the 26000000- range. It's not > > a problem with telnet or sendfile as such... I suspect something more. > > You can suspect all you want, I'll be looking at facts. So far, it seems to be > going to WONTFIX land. Fine. Put up with it and stay in Non-HTTP-Compliant Land :P
(In reply to comment #6) > Fine. Put up with it and stay with Non-HTTP-Compliant Land :P You know, I had figured already you were a whiner.
(In reply to comment #8) > (In reply to comment #6) > > Fine. Put up with it and stay with Non-HTTP-Compliant Land :P > You know, I had figured already you were a whiner. Guys, can we keep this professional? Karthik: what Remy is saying is that he needs more than just a "suspicion", as in a documented, **self-contained**, test case which demonstrates the problem.
The issue is now fixed (incorrect length parameter passed to the sendfile call), as submitted by Mladen Turk.
(In reply to comment #10) > The issue is now fixed (incorrect length parameter passed to the sendfile call), > as submitted by Mladen Turk. It's not closed dammit remm.. If the number of bytes asked for is <4KB (at the end of the file), it doesn't work. It's tested. It's with and without the APR binary. It's still a bug
Sorry about that. thanx for fixing. :-) Next time remm... please be more considerate while replying.