Serving graphics from a database

I want to store frequently-used graphic elements in a db and serve
them from there rather than from the filesystem.

Is there a better/faster way to do that than this? (error checking
etc not shown)

The relevant piece of the page:
<?php
echo
'<table><tr><td>
<img src="ImageFromDB.php?Image=ImageIdentifer">
</td></tr></table>' ;
?>

ImageFromDB.php:
<?php
$imgname = $_GET['Image'] ;
$dset = mysql_query( 'SELECT imagebits FROM graphics_table
WHERE name="' . $imgname . '"' ) ;
$rec = mysql_fetch_row($dset) ;
$browser = fopen( 'php://output', 'w') ;
header( 'Content-Type: image/png' ) ;
fwrite( $browser, $rec[0] ) ;
?>

I fingered through the docs and did some googling, but didn't find
anything obviously helpful. Many thanks for any insights.

Margaret
--
(To mail me, please change .not.invalid to .net, first.
Apologies for the inconvenience.)

"Margaret MacDonald" wrote:[color=blue]
> I want to store frequently-used graphic elements in a db and serve
> them from there rather than from the filesystem.
>
> Is there a better/faster way to do that than this? (error checking
> etc not shown)
>
> The relevant piece of the page:
> <?php
> echo
> ’<table><tr><td>
> <img src="ImageFromDB.php?Image=ImageIdentifer">
> </td></tr></table>’ ;
> ?>
>
> ImageFromDB.php:
> <?php
> $imgname = $_GET[’Image’] ;
> $dset = mysql_query( ’SELECT imagebits FROM graphics_table
> WHERE name="’ . $imgname .
> ’"’ ) ;
> $rec = mysql_fetch_row($dset) ;
> $browser = fopen( ’php://output’, ’w’) ;
> header( ’Content-Type: image/png’ ) ;
> fwrite( $browser, $rec[0] ) ;
> ?>
>
> I fingered through the docs and did some googling, but didn’t
> find
> anything obviously helpful. Many thanks for any insights.
>
> Margaret[/color]

Margaret, your script and db are going thru a lot of processing just
to serve frequently used images. Why not save them on disk, and put
their path (or file name) in the db. Is there an important reason
to save them to db?

--
http://www.dbForumz.com/ This article was posted by author's request
Articles individually checked for conformance to usenet standards
Topic URL: http://www.dbForumz.com/PHP-Serving-...ict139672.html
Visit Topic URL to contact author (reg. req'd). Report abuse: http://www.dbForumz.com/eform.php?p=467181

steve wrote:
[color=blue]
>"Margaret MacDonald" wrote:[color=green]
> > I want to store frequently-used graphic elements in a db and serve
> > them from there rather than from the filesystem.
> >
> > Is there a better/faster way to do that than this? (error checking
> > etc not shown)
> >
> > The relevant piece of the page:
> > <?php
> > echo
> > ’<table><tr><td>
> > <img src="ImageFromDB.php?Image=ImageIdentifer">
> > </td></tr></table>’ ;
> > ?>
> >
> > ImageFromDB.php:
> > <?php
> > $imgname = $_GET[’Image’] ;
> > $dset = mysql_query( ’SELECT imagebits FROM graphics_table
> > WHERE name="’ . $imgname .
> > ’"’ ) ;
> > $rec = mysql_fetch_row($dset) ;
> > $browser = fopen( ’php://output’, ’w’) ;
> > header( ’Content-Type: image/png’ ) ;
> > fwrite( $browser, $rec[0] ) ;
> > ?>
> >
> > I fingered through the docs and did some googling, but didn’t
> > find
> > anything obviously helpful. Many thanks for any insights.
> >
> > Margaret[/color]
>
>Margaret, your script and db are going thru a lot of processing just
>to serve frequently used images. Why not save them on disk, and put
>their path (or file name) in the db. Is there an important reason
>to save them to db?[/color]

Mainly as a security thing, Steve. The people for whom I'm doing this
project expect relentless attacks to be made on their site (I suspect
that they're probably right) so my goal is to make the whole thing as
seamless and opaque as I possibly can.

Margaret
--
(To mail me, please change .not.invalid to .net, first.
Apologies for the inconvenience.)

I wrote:[color=blue]
>... my goal is to make the whole thing as
>seamless and opaque as I possibly can.[/color]

That should have been 'as I possibly can consistent with usable
performance'.

Margaret
--
(To mail me, please change .not.invalid to .net, first.
Apologies for the inconvenience.)

"Margaret MacDonald" wrote:[color=blue]
> I wrote:[color=green]
> >... my goal is to make the whole thing as
> >seamless and opaque as I possibly can.[/color]
>
> That should have been ’as I possibly can consistent with usable
> performance’.
>
> Margaret[/color]

Margaret, are you talking about stopping leeching, i.e. people linking
to these images. If that is the case, there are many other solutions.
Check for "anti-leeching" on search engines.

--
http://www.dbForumz.com/ This article was posted by author's request
Articles individually checked for conformance to usenet standards
Topic URL: http://www.dbForumz.com/PHP-Serving-...ict139672.html
Visit Topic URL to contact author (reg. req'd). Report abuse: http://www.dbForumz.com/eform.php?p=467277

steve wrote:
[color=blue]
>"Margaret MacDonald" wrote:[color=green]
> > I wrote:[color=darkred]
> > >... my goal is to make the whole thing as
> > >seamless and opaque as I possibly can.[/color]
> >
> > That should have been ’as I possibly can consistent with usable
> > performance’.
> >
> > Margaret[/color]
>
>Margaret, are you talking about stopping leeching, i.e. people linking
>to these images. If that is the case, there are many other solutions.
> Check for "anti-leeching" on search engines.[/color]

No, actually I don't care about that, Steve--they can always grab the
image from the screen if that's what they want. My purpose is to
frustrate the ones who will be trying to collect information as a
prelude to and tool for breaking in. If they can't learn the
filesystem structure or filenames, it becomes that much harder for
them to attack the system.

Margaret
--
(To mail me, please change .not.invalid to .net, first.
Apologies for the inconvenience.)

On Sat, 14 Aug 2004 13:28:17 GMT, Margaret MacDonald
<scratch65536@att.not.invalid> wrote:
[color=blue]
>I want to store frequently-used graphic elements in a db and serve
>them from there rather than from the filesystem.
>
>Is there a better/faster way to do that than this? (error checking
>etc not shown)
>
>The relevant piece of the page:
><?php
> echo
> '<table><tr><td>
> <img src="ImageFromDB.php?Image=ImageIdentifer">
> </td></tr></table>' ;
>?>
>
>ImageFromDB.php:
><?php
> $imgname = $_GET['Image'] ;
> $dset = mysql_query( 'SELECT imagebits FROM graphics_table
> WHERE name="' . $imgname . '"' ) ;
> $rec = mysql_fetch_row($dset) ;
> $browser = fopen( 'php://output', 'w') ;
> header( 'Content-Type: image/png' ) ;
> fwrite( $browser, $rec[0] ) ;
>?>
>
>I fingered through the docs and did some googling, but didn't find
>anything obviously helpful. Many thanks for any insights.[/color]

Looks OK to me. A plain 'print' would likely do just as well as opening the
output stream as you've done, but there's nothing wrong with that. You might
want to change the mode to 'wb' though to indicate binary mode.

If these images are frequently accessed then it might be worth considering
using a filesystem-based cache if the database queries take noticable amounts
of resources.

General opinion on this group is to not store images in a database and instead
just store a filesystem path. However, I believe that if the images are

(a) user data rather than static source code of the site
(b) have relationships with data in the database
(c) have any sort of value with regards to the end-user

... then it's worth considering storing them in full in the database so you
can include them consistently in the database backups, and have the same
transaction guarantees as all the other data on them.

--
Andy Hassall / <andy@andyh.co.uk> / <http://www.andyh.co.uk>
<http://www.andyhsoftware.co.uk/space> Space: disk usage analysis tool

"Margaret MacDonald" wrote:[color=blue]
> steve wrote:
>[color=green]
> >"Margaret MacDonald" wrote:[color=darkred]
> > > I wrote:
> > > >... my goal is to make the whole thing as
> > > >seamless and opaque as I possibly can.
> > >
> > > That should have been ’as I possibly can consistent with usable
> > > performance’.
> > >
> > > Margaret[/color]
> >
> >Margaret, are you talking about stopping leeching, i.e. people[/color]
> linking[color=green]
> >to these images. If that is the case, there are many other[/color]
> solutions.[color=green]
> > Check for "anti-leeching" on search engines.[/color]
>
> No, actually I don’t care about that, Steve--they can always
> grab the
> image from the screen if that’s what they want. My purpose is
> to
> frustrate the ones who will be trying to collect information as a
> prelude to and tool for breaking in. If they can’t learn the
> filesystem structure or filenames, it becomes that much harder for
> them to attack the system.
>
> Margaret[/color]

oh, I see. Sorry if I have taken the thread off-track (?). In any
case, you can always mask the file system with php. No need to pull
from db, same effect. Ok, sorry again.

"Margaret MacDonald" <scratch65536@att.not.invalid> wrote in message
news:uc6th0h7tqoqm0lvgn766sbiou2e28vcsk@4ax.com...[color=blue]
> steve wrote:
>[color=green]
> >"Margaret MacDonald" wrote:[color=darkred]
> > > I wrote:
> > > >... my goal is to make the whole thing as
> > > >seamless and opaque as I possibly can.
> > >
> > > That should have been 'as I possibly can consistent with usable
> > > performance'.
> > >
> > > Margaret[/color]
> >
> >Margaret, are you talking about stopping leeching, i.e. people linking
> >to these images. If that is the case, there are many other solutions.
> > Check for "anti-leeching" on search engines.[/color]
>
> No, actually I don't care about that, Steve--they can always grab the
> image from the screen if that's what they want. My purpose is to
> frustrate the ones who will be trying to collect information as a
> prelude to and tool for breaking in. If they can't learn the
> filesystem structure or filenames, it becomes that much harder for
> them to attack the system.[/color]

Apache rewrite is probably a better solution here.

steve wrote:
[color=blue][color=green][color=darkred]
> > >Margaret, are you talking about stopping leeching, i.e. people[/color]
> > linking[color=darkred]
> > >to these images. If that is the case, there are many other[/color]
> > solutions.[color=darkred]
> > > Check for "anti-leeching" on search engines.[/color]
> >
> > No, actually I don’t care about that, Steve--they can always
> > grab the
> > image from the screen if that’s what they want. My purpose is
> > to
> > frustrate the ones who will be trying to collect information as a
> > prelude to and tool for breaking in. If they can’t learn the
> > filesystem structure or filenames, it becomes that much harder for
> > them to attack the system.
> >
> > Margaret[/color]
>
>oh, I see. Sorry if I have taken the thread off-track (?). In any
>case, you can always mask the file system with php. No need to pull
>from db, same effect. Ok, sorry again.[/color]

No, actually I'm glad you brought up leeching, Steve, so: thanks! As
you can tell from my response to you, I misunderstood what you meant
(I hadn't heard the term 'leeching' in this context before). Yes, I
can now see that preventing leeching will be an issue as well. My
problem is that web development is a completely new thing for me--my
experience has all been with shrinkwrap and systems software--so there
are plenty factors that simply don't occur to me til someone else
brings them up--usually by accident :-)

Margaret
--
(To mail me, please change .not.invalid to .net, first.
Apologies for the inconvenience.)

Chung Leong wrote:
[color=blue]
>"Margaret MacDonald" <scratch65536@att.not.invalid> wrote in message
>news:uc6th0h7tqoqm0lvgn766sbiou2e28vcsk@4ax.com.. .[color=green]
>> steve wrote:
>>[color=darkred]
>> >"Margaret MacDonald" wrote:
>> > > I wrote:
>> > > >... my goal is to make the whole thing as
>> > > >seamless and opaque as I possibly can.
>> > >
>> > > That should have been 'as I possibly can consistent with usable
>> > > performance'.
>> > >
>> > > Margaret
>> >
>> >Margaret, are you talking about stopping leeching, i.e. people linking
>> >to these images. If that is the case, there are many other solutions.
>> > Check for "anti-leeching" on search engines.[/color]
>>
>> No, actually I don't care about that, Steve--they can always grab the
>> image from the screen if that's what they want. My purpose is to
>> frustrate the ones who will be trying to collect information as a
>> prelude to and tool for breaking in. If they can't learn the
>> filesystem structure or filenames, it becomes that much harder for
>> them to attack the system.[/color]
>
>Apache rewrite is probably a better solution here.
>[/color]
I'll look into it, Chung. Thanks!

Margaret
--
(To mail me, please change .not.invalid to .net, first.
Apologies for the inconvenience.)

Andy Hassall wrote:
[color=blue]
>On Sat, 14 Aug 2004 13:28:17 GMT, Margaret MacDonald
><scratch65536@att.not.invalid> wrote:
>[color=green]
>>I want to store frequently-used graphic elements in a db and serve
>>them from there rather than from the filesystem.
>>
>>Is there a better/faster way to do that than this? (error checking
>>etc not shown)
>>
>>The relevant piece of the page:
>><?php
>> echo
>> '<table><tr><td>
>> <img src="ImageFromDB.php?Image=ImageIdentifer">
>> </td></tr></table>' ;
>>?>
>>
>>ImageFromDB.php:
>><?php
>> $imgname = $_GET['Image'] ;
>> $dset = mysql_query( 'SELECT imagebits FROM graphics_table
>> WHERE name="' . $imgname . '"' ) ;
>> $rec = mysql_fetch_row($dset) ;
>> $browser = fopen( 'php://output', 'w') ;
>> header( 'Content-Type: image/png' ) ;
>> fwrite( $browser, $rec[0] ) ;
>>?>
>>
>>I fingered through the docs and did some googling, but didn't find
>>anything obviously helpful. Many thanks for any insights.[/color]
>
> Looks OK to me. A plain 'print' would likely do just as well as opening the
>output stream as you've done, but there's nothing wrong with that. You might
>want to change the mode to 'wb' though to indicate binary mode.
>
> If these images are frequently accessed then it might be worth considering
>using a filesystem-based cache if the database queries take noticable amounts
>of resources.
>
> General opinion on this group is to not store images in a database and instead
>just store a filesystem path. However, I believe that if the images are
>
>(a) user data rather than static source code of the site
>(b) have relationships with data in the database
>(c) have any sort of value with regards to the end-user
>
> ... then it's worth considering storing them in full in the database so you
>can include them consistently in the database backups, and have the same
>transaction guarantees as all the other data on them.[/color]

Thanks, Andy. I didn't even experiment with print() since I presumed
it would do gratuitous interpretation. And thanks for catching the
'b'--I seem to have a habit of missing that out.

Your articulation of when/why it can be good to store images in the db
fits for me.

Margaret
--
(To mail me, please change .not.invalid to .net, first.
Apologies for the inconvenience.)

On Sun, 15 Aug 2004 13:50:41 +0000, Margaret MacDonald wrote:
[color=blue][color=green]
>>oh, I see. Sorry if I have taken the thread off-track (?). In any
>>case, you can always mask the file system with php. No need to pull
>>from db, same effect. Ok, sorry again.[/color]
>
> No, actually I'm glad you brought up leeching, Steve, so: thanks! As
> you can tell from my response to you, I misunderstood what you meant
> (I hadn't heard the term 'leeching' in this context before). Yes, I
> can now see that preventing leeching will be an issue as well. My
> problem is that web development is a completely new thing for me--my
> experience has all been with shrinkwrap and systems software--so there
> are plenty factors that simply don't occur to me til someone else
> brings them up--usually by accident :-)[/color]

<img src="/image.php/1" alt="Image 1" />

<?php
$images = array(
1 => '/full/path/to/image_1.png',
[ ... ]
);

$pi = explode('/', $_SERVER['PATH_INFO']);

if (file_exists($images[intavl($pi[1])])) {
header('Content-type: image/png');
readfile($images[intval($pi[1])]);
exit;
}
?>

Note, this is extremely simplified (and not optimised), but would disclose
no path to your users and still allow filesystem storage.

You could implement sessions or the likes to cut down maybe on hotlinking,
but outright preventing hotlinking is just a myth =)

HTH.

Regards,

Ian

--
Ian.H
digiServ Network
London, UK
http://digiserv.net/

Margaret MacDonald wrote:[color=blue]
> Andy Hassall wrote:
>
>[color=green]
>>On Sat, 14 Aug 2004 13:28:17 GMT, Margaret MacDonald
>><scratch65536@att.not.invalid> wrote:
>>
>>[color=darkred]
>>>I want to store frequently-used graphic elements in a db and serve
>>>them from there rather than from the filesystem.
>>>
>>>Is there a better/faster way to do that than this? (error checking
>>>etc not shown)
>>>
>>>The relevant piece of the page:
>>><?php
>>> echo
>>> '<table><tr><td>
>>> <img src="ImageFromDB.php?Image=ImageIdentifer">
>>> </td></tr></table>' ;
>>>?>
>>>
>>>ImageFromDB.php:
>>><?php
>>> $imgname = $_GET['Image'] ;
>>> $dset = mysql_query( 'SELECT imagebits FROM graphics_table
>>> WHERE name="' . $imgname . '"' ) ;
>>> $rec = mysql_fetch_row($dset) ;
>>> $browser = fopen( 'php://output', 'w') ;
>>> header( 'Content-Type: image/png' ) ;
>>> fwrite( $browser, $rec[0] ) ;
>>>?>
>>>
>>>I fingered through the docs and did some googling, but didn't find
>>>anything obviously helpful. Many thanks for any insights.[/color]
>>
>>Looks OK to me. A plain 'print' would likely do just as well as opening the
>>output stream as you've done, but there's nothing wrong with that. You might
>>want to change the mode to 'wb' though to indicate binary mode.
>>
>>If these images are frequently accessed then it might be worth considering
>>using a filesystem-based cache if the database queries take noticable amounts
>>of resources.
>>
>>General opinion on this group is to not store images in a database and instead
>>just store a filesystem path. However, I believe that if the images are
>>
>>(a) user data rather than static source code of the site
>>(b) have relationships with data in the database
>>(c) have any sort of value with regards to the end-user
>>
>>... then it's worth considering storing them in full in the database so you
>>can include them consistently in the database backups, and have the same
>>transaction guarantees as all the other data on them.[/color]
>
>
> Thanks, Andy. I didn't even experiment with print() since I presumed
> it would do gratuitous interpretation. And thanks for catching the
> 'b'--I seem to have a habit of missing that out.
>
> Your articulation of when/why it can be good to store images in the db
> fits for me.
>
> Margaret[/color]

The only real downside on storing images s a database is if you're using
a system-based backup procidure. Then, every time oyu change an image,
then the whole data file needs to be saved again, and images tend not to
be small.

So why not apply the same logic above to the file name, and then store
the images somewhere else. That way they can be backed up individually
when they change, not en masse.

$0.02

Steve