Fundamental question about nature of jigsaw caching

Garrick Toubassi writes:
 > I apologize in advance for the basic question, but I have read through
 > the jigsaw docs and am still confused.
 > 
 > Basically I am using jigsaw to vend a java applet, and it was
 > complaining about some gif images that it couldn't find.  It turns out
 > that our code was referring to the images with the improper case (.gif
 > vs .GIF), which normally would work on windows.  Anyway, I fired up the
 > property editor and changed the check-sensitivity property to false, and
 > saved the properties and restarted the server.  It worked like a charm. 
 > The app came up fine.
 > 
 > I installed a newer version of the applet and the problem came back.  I
 > tried switching the case-sensitivity property but that didn't help.  I
 > probably did something in a different order, or maybe I actually killed
 > the server, edited the httpd.props, and restarted it manually.  I dont
 > remember.
 > 
 > Anyway, the question I have is if jigsaw's caching could cause this
 > problem to linger.  If so, whats the correct way to change properties
 > and make sure everything is kosher?

The check-sensitivity flag does not mean what you think (I guess):
When set to false, Jigsaw expect the file system to be case sensitive,
hence it relies on the file system to distibguish between "/Admin" and
"/AdMin". 
When set to true, Jigsaw expect directory listings to be in proper
case, and when a requested URL is not found, it lists the directory to
get the proper case, which is compared to the requested URL part.

So, whatever happens, if getting foo.GIF works, then getting foo.gif
will not work, however, as extensions are now case insensitive, both
foo.gif and foo.GIF will be indexed using either GIF or gif extension
declaration.

URLs are specified as being case sensitive, that's why Jigsaw has it.

Anselm.

Received on Tuesday, 22 October 1996 02:25:34 UTC