DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17537>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17537 2.0.44 (and earlier) fail to serve .jpg files on RedHat 7.3 Summary: 2.0.44 (and earlier) fail to serve .jpg files on RedHat 7.3 Product: Apache httpd-2.0 Version: 2.0.44 Platform: PC OS/Version: Linux Status: NEW Severity: Major Priority: Other Component: Core AssignedTo: bugs@httpd.apache.org ReportedBy: [EMAIL PROTECTED] In short, a RedHat 7.3 system I have with 2.0.44 installed refuses to serve .jpg files but will serve other types without problems (.gif, .html, etc). I've also seen this behavior occur with 2.0.39 as well under RH 7.3. Nothing is logged about the request in the access or error logs although /server-status does show the request being processed. I have several other systems running RH 7.1 and RH 8.0 that do not exhibit this problem with httpd 2 built the same way (built with: ./configure --prefix=/usr/local/image-server --disable-autoindex --disable-cgid --disable-cgi --disable-userdir). Also 1.3.27 on the same RH7.3 system serves the image just fine. A HEAD of the image results in: 200 OK Connection: close Date: Fri, 28 Feb 2003 16:52:23 GMT Accept-Ranges: bytes ETag: "19319b-29ad-1f466980" Server: Apache/2.0.44 (Unix) Content-Length: 10669 Content-Type: image/jpeg Last-Modified: Thu, 27 Feb 2003 23:15:02 GMT Client-Date: Fri, 28 Feb 2003 16:51:29 GMT Client-Response-Num: 1 But if I use wget I see: Resolving host.example.com... done. Connecting to host.example.com[ip.ad.dr.ess]:8000... connected. HTTP request sent, awaiting response... 200 OK Length: 10,669 [image/jpeg] 0% [ ] 0 --.--K/s ETA --:-- 11:52:01 (0.00 B/s) - Connection closed at byte 0. Retrying. and then repeats the above until I Ctrl-C Mozilla reports that it couldn't be displayed due to errors in the file and IE gives a broken image tag. Again there is nothing logged in the access or error logs and various other file types work without problems. It's just the jpegs that fail. My httpd.conf is an almost verbatim copy of the bundled highperformance.conf (only the paths for docroot and logging have been changed, and the port set to 8000) A strace of the process during one such request shows: accept(3, {sin_family=AF_INET, sin_port=htons(49247), sin_addr=inet_addr("client.ip.addr.ess")}}, [16]) = 8 gettimeofday({1046453150, 164649}, NULL) = 0 getsockname(8, {sin_family=AF_INET, sin_port=htons(8000), sin_addr=inet_addr("10.33.1.12")}}, [16]) = 0 gettimeofday({1046453150, 165039}, NULL) = 0 brk(0x812d000) = 0x812d000 fcntl64(8, F_GETFL) = 0x2 (flags O_RDWR) fcntl64(8, F_SETFL, O_RDWR|O_NONBLOCK) = 0 brk(0x8130000) = 0x8130000 read(8, 0x812bf80, 8000) = -1 EAGAIN (Resource temporarily unavailable) poll([{fd=8, events=POLLIN, revents=POLLIN}], 1, 300000) = 1 read(8, "GET /path/to/image.jpg"..., 8000) = 670 gettimeofday({1046453150, 178005}, NULL) = 0 gettimeofday({1046453150, 178229}, NULL) = 0 stat64("/path/to/image.jpg", {st_mode=S_IFREG|0644, st_size=10669, ...}) = 0 open("/path/to/image.jpg", O_RDONLY) = 9 open("/etc/localtime", O_RDONLY) = 10 fstat64(10, {st_mode=S_IFREG|0644, st_size=1267, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40028000 read(10, "TZif\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\4\0\0\0\4\0"..., 4096) = 1267 close(10) = 0 munmap(0x40028000, 4096) = 0 brk(0x8133000) = 0x8133000 setsockopt(8, SOL_TCP, TCP_NODELAY, [0], 4) = 0 setsockopt(8, SOL_TCP, TCP_CORK, [1], 4) = 0 writev(8, [{"HTTP/1.1 200 OK\r\nDate: Fri, 28 F"..., 290}], 1) = 290 sendfile(8, 9, [0], 10669) = -1 EINVAL (Invalid argument) setsockopt(8, SOL_TCP, TCP_CORK, [0], 4) = 0 setsockopt(8, SOL_TCP, TCP_NODELAY, [1], 4) = 0 read(8, 0x812bf80, 8000) = -1 EAGAIN (Resource temporarily unavailable) brk(0x8136000) = 0x8136000 write(4, "client.ip.addr.ess - - [28/Feb/2003:1"..., 187) = 187 ^^^ Note that this doesn't appear in the logs despite this write() times({tms_utime=0, tms_stime=0, tms_cutime=0, tms_cstime=0}) = 33404006 gettimeofday({1046453150, 181153}, NULL) = 0 close(8) = 0 read(5, 0xbfffe0a3, 1) = -1 EAGAIN (Resource temporarily unavailable) close(9) = 0 gettimeofday({1046453150, 183951}, NULL) = 0 accept(3, <unfinished ...> If there's any additional information I can provide you with to help track this down, please let me know. Thanks, Tabor --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]