[lug] Safely Parsing PHP Parameters

[dio2002 at indra.com]

> On Wed, 2007-10-10 at 14:58 -0600, dio2002 at indra.com wrote:
> [snip]
>> i'd actually recommend that you do NOT cache in this manner unless you
>> have oodles of traffic.  it's not worth the hastle and the performance
>> will be negligble for light loads which the majority of websites usually
>> encounter.
>
> I'd like to take every web author that takes this advice and shake them
> by the neck.
>
> Caching helps the user just as much as the site owner.  As a site user I
> don't care about your bandwidth bill.  I care about how long it takes to
> load your pages.
>
> At home I have a relatively slow connection.  Caching helps a lot!  I do
> not want to reload every old image whenever I visit (the archives of a
> web comic, for example).  I have a 40 GB squid cache for a *reason*.
>
> In a situation like this, think of clicking the Next link several times.
> Without any caching, the whole page reloads.  (1.5s on modem) With IMS
> caching, there is a server round-trip (150-300 ms on modem).  With
> Expires caching, no server response is needed and Next clicks will load
> as quickly as possible (~20 ms), assuming that the page was already in
> cache (and link rel=prefetch can even assure this on Firefox).
>
> Squid even takes Expires into account when determining how long to hold
> objects in cache.  IMS objects get shorter times.
>
> Waiting for your site design to stabilize is a good reason.  But it is
> relatively painless (or it should be) to rename a directory and update a
> PHP variable to go from one version of the site to another.

i think my post was taken a little out of context and i probably didn't
state well.  caching IS fine and works wonders for speed.  DO use it. 
just make sure you know what you're doing and the tradeoffs.  *while* i'm
*developing* sites, i guess i prefer to leave it off or make sure i know
what file types are being cached (for flash or photo gallery work for
instance).  when a lot is changing, i have found it to create more
problems at this stage. i also like to keep my directory structures
consistent across sites / clients.   changing paths to expire the cache is
not what i usually want to do.  i guess it really comes down to knowing
how the caches work.  if you set the expire to 10 years and you hand off a
site to a client that doesn't know how to use it, they will edit a site
page that is never seen by their audience unless they just happen to
delete their browser cache. a shorter expire time is sometimes more
functional especially for content you know will be changing (and where
path changes are not part of the recipe).

> --
> Zan Lynx <zlynx at acm.org>
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> Join us on IRC: lug.boulder.co.us port=6667 channel=#colug