Jeremy Smith's blog

Entry Is Labelled

HTTP and Microformats

Remember when everyone realized that HTTP was really good at what it did and since we already knew it, we should just use it and stop going crazy with proprietary / complex / lesser known protocols?
I think that only like 3% of people have realized that. The other 97% are still using huge "frameworks" and "stacks" to implement something as simple as caching et al.
But that's not what the article focuses on. Go read it. It describes use-cases for microformats.

Comments

  1. gravatar

    Are you sure there are web frameworks that re-implement client-side caching? Whenever I have seen caching listed as a framework feature, it means managing server-side caching, which has nothing to do with HTTP.

  2. gravatar
    Are you sure there are web frameworks that re-implement client-side caching? ... it means managing server-side caching, which has nothing to do with HTTP.

    They don't re-implement client side caching, per se. What they do is uselessly use server-side caching, when responding with 304s would do just fine.

  3. gravatar

    But are you sure that they're using server-side caching for the same reason 304s exist, which would (as you suggest) be silly? Preventing the server from spending CPU time *regenerating* content that hasn't been updated is a different issue from preventing the server from *resending* content the client already has.

  4. gravatar
    Preventing the server from spending CPU time *regenerating* content that hasn't been updated is a different issue from preventing the server from *resending* content the client already has.

    Affirmative. Indeed it is.

    Some web frameworks' "caching layers" send "200 - Ok" responses even when the data it has is the same data the client has. That's just the tip of the iceberg. Conditional GETs open up a whole other side of the coin that many web frameworks like to pretend doesn't exist.

Post a comment