> A good suggestion. 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"> > It's strange that there is no error on httpd's log: if you can't see the image, it means that httpd can not find the file where it searches for it and you should see a "File does not not exist" error, or something like that Are you sure you have not some rewrite rules somewhere acting on the string "ad_...."? Regards, Gaël --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|