apache problem with soft link

[Michael D. Berger]

> Michael D. Berger wrote:
> >>On 1/23/06, Michael D. Berger <m.d.berger at ieee.org> wrote:
> >>
> >>>The appropriate directories all have SymLinksIfOwnerMatch (and
> >>
> >>Does the final directory have the proper permissions as detailed in
> >>httpd.conf ?  All directories must be defined in the 
> httpd.conf file.
> > 
> > 
> > It has >not< been my experience that all of the directories must be
> > defined in the httpd.conf, nor have I seen that in the 
> documentation.
> > In fact, none of the numerous directories that contain the 
> jpg file are,
> > and most of them work.  Directories in the http tree >or 
> their parents<
> > are defined in httpd.config. All directories and files are 
> readable by
> > all.  I would like to hear other opinions on this.
> > 
> > Here is come additional information.
> > 
> > The httpd logs show correct delivery, including an exactly
> > correct file length, despite failure. This suggested that
> > the problem might be on the receiving end.  The failure is
> > seen two two boxes of different hardware, but with similar
> > win2k systems. I did test it with firefox on the server box
> > using file:///... and it works correctly.  I don't have another
> > linux box I can test it with.
> > 
> > The strangest thing is that the problem is critically
> > dependent on the soft link name.  I have tried numerous
> > combinations, and can make no sense of it.  For example:
> > 
> > These fail:
> >    <img src="Ad_land_small_1/01590004FS.jpg">
> >    <img src="ad_land_small_1/01590004FS.jpg">
> > 
> > Thess work:
> >    <img src="Bd_land_small_1/01590004FS.jpg">
> >    <img src="adddd_land_small_1/01590004FS.jpg">
> > 
> > In all cases, the correct links are in place.
> > 
> > You can see where my work-around is comming from.
> > Thanks for your help.
> > 
> > Mike.
> > 
> > --
> > Michael D. Berger
> > m.d.berger at ieee.org 
> > 
> > 
> > 
> 
> What do your apache logs tell you that apache is actually 
> serving up in these 
> cases? If a request fails it should be logged in (the default 
> location) 
> /var/log/httpd/error_log, and if you have logging enabled the 
> successful 
> requests will be logged in /var/log/httpd/access_log.
> 
> If that doesn't show anything useful, run ethereal and 
> capture the transfer to 
> see what request is coming in from the client, and what 
> response is being sent 
> back by the server.
> 
> -- 
> Nigel Wade, System Administrator, Space Plasma Physics Group,

The logs showed normal behavior.  I did take a look with
ethereal, and then hoped that the problem could be solved
by other means, since there is a large amount of data to
examine.  As you can see, the problem has been solved, at
least up to a point.

Thanks,
Mike.
--
Michael D. Berger
m.d.berger at ieee.org