in reply to Re: Displaying Image located outside web server dir
in thread Displaying Image located outside web server dir

Hey

I was just thinking about this topic because I will probably be doing something similar.

What if you used perl to copy the image to a directory inside your web server directory, then have it displayed through html like normal, then after thats done, have perl delete the image you copied? (sort of like a temp file)

That way the image can be displayed, but when someone tries to save, it will not find the image since its deleted?

I'm not sure if this method will work. Anyone have any comments on the flaws with this method?

perleager
  • Comment on Re: Displaying Image located outside web server dir

Replies are listed 'Best First'.
Re^2: Displaying Image located outside web server dir
by jhourcle (Prior) on May 07, 2005 at 17:45 UTC

    Once the browser has it, they have it in their cache, and can regenerate it from the cache. It doesn't matter if it's still on the webserver or not.

    As eibwen mentioned -- the file has to be available to the browser for it to be displayed. You have absolutely no control over what the browser can do with an image once they have it. (I've seen sites that use javascript so they can try to keep you from right clicking on an image, but that doesn't help someone linking directly to the image (not through the page you intended), or just turning off javascript.).

      Ahh didn't think about that. I knew that there had to be some way to work around that method, just couldn't think of it.

      :)
Re^2: Displaying Image located outside web server dir
by CountZero (Bishop) on May 07, 2005 at 23:20 UTC
    This could turn ugly very quick, with all kinds of race conditions rearing their heads. How do you know when to delete the file? What do you do if the connection gets broken before the whole file is transmitted? You could end up with lots of "old" files sitting around which will need to be reaped after some time. What if several requests come in almost simultaneously? You can't have different files, so all requests will have to "share" the same file and you will need to implement some locking system.

    I don't think it is worth the trouble as anyhow once the file is transmitted to the browser, there is no way you can stop him from saving the file.

    CountZero

    "If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law