httpd-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 17537] New: - 2.0.44 (and earlier) fail to serve .jpg files on RedHat 7.3
Date Fri, 28 Feb 2003 17:32:33 GMT
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: apache.org@fsckit.net


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: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org


Mime
View raw message