Oh no Oh no Oh no Yo yo yo Oh no you didn't Sucka tried to play me But you never paid me, Neva Oh no you didn't Payback is a' comin' You will be runnin', foreva Oh no you didn't Until i get my vengeance I will never end this mayhem Oh no you didn't I'm a mercenary You ain't got a prayer, you owe meeee Oh no you didn't
First you tried to trap me Then you bust a cap in, my ass Oh no you didn't Such humiliation will bring annihilation, at last Oh no you didn't It will be delicious when I get vicious, tomorrow Oh no you didn't There's no second chances
Mercenaries Playground of Destruction is one of my favorite games for the PS2 and I've eagerly been awaiting Mercenaries 2. It was supposed to come out this Spring but had 5 months late. I haven't picked it up yet
From: "Bell, Nick (HP Software, ASC)" <nbell@--.com> To: "Hoffman, Billy" <billy.hoffman@--.com> CC: "Malia, Celeste" Date: Thu, 4 Sep 2008 16:40:21 +0000 Subject: You at age 50
Hey Billy,
Celeste and I are at the Forrester Security Forum and we have just seen a glimpse of what you will be like at the age 50. Celeste sees you as this guys 'mini me'.
Slow down on the Red Bull
Nick & Celeste
PS. His name is Gary McGraw from Cigital
No way. Gary McGraw shits more 1337ness in a week than I've done in 12+ years of hacking.
Its early (Actually very very late). Still trying to understand the implication of this. Lots of people in the web security space and beyond have been saying it for years: The browser is the new OS and JavaScript is the new shell code.
Only it was never designed to be an OS.
The long awaited Google OS is an open source web browser. I'm going to sleep.
(PS. Did I miss read page 10 through blurry sleep dep eyes? Did google really couple an input fuzzer to a web crawler for public sites?)
As I've mentioned, there is a business intelligence guy at work who is basically a glorified RSS feed reader. However every now and then there is a nice "under non-disclosure" piece that comes through that makes me glad I re-thought killfiling him.
IBM Jimmy brought some Handy Baggers by the office today. They are made out of solid aluminum and are really quite useful. If you feel like you are going to lose some fingers when moving multiple bags, paint cans, and the like you should check these out!
Once upon a midnight dreary, while I websurfed, weak and weary, Over many a strange and spurious website of 'hot chicks galore', While I clicked my fav'rite bookmark, suddenly there came a warning, And my heart was filled with mourning, mourning for my dear amour. "'Tis not possible," I muttered, "Give me back my cheap hardcore!"
HTTP Caching is bretarded: Or, how I learn to stop worrying and accept that 'no-cache' actually does cache.
Topic: Miscellaneous
12:47 am EDT, Aug 24, 2008
HTTP Caching is now added to my growing list of things that are Bretarded. Behold RFC2616:
no-cache
If the no-cache directive does not specify a field-name, then a cache MUST NOT use the response to satisfy a subsequent request without successful revalidation with the origin server. This allows an origin server to prevent caching even by caches that have been configured to return stale responses to client requests.
In other words, HTTP responses with a no-cache directive will actually be cached by downstream web caches. However when subsequent requests for that resource come into the cache, the cache must send a conditional GET to the original web server to check if the response it has cached is ok to serve.
So no-cache actually means cache, but revalidate.
... ok... so what about the must-revalidate directive?
must-revalidate
Because a cache MAY be configured to ignore a server's specified expiration time, and because a client request MAY include a max- stale directive (which has a similar effect), the protocol also includes a mechanism for the origin server to require revalidation of a cache entry on any subsequent use. When the must-revalidate directive is present in a response received by a cache, that cache MUST NOT use the entry after it becomes stale to respond to a subsequent request without first revalidating it with the origin server. (I.e., the cache MUST do an end-to-end revalidation every time, if, based solely on the origin server's Expires or max-age value, the cached response is stale.)
Great, so must-revalidate actually means the cache must send a conditional GET to the original server to revalidate the cached respoinse, but only if that response is stale. IF the cache still thinks the response is "fresh" it can serve a cached response regardless of the "must-revalidate" header.
Welcome to the fucked up world of HTTP caching! Of course, all this craziness is based on the premise that User-Agents can tell caches to give them stale resources. Which was probably a fairly bad idea in the mid-90s "the web is a series of static documents connected by hyperlinks" view of the world, and is an utterly horrible idea in the Web 2.0 view of the world.
There are absolutely no good comprehensive resources that explain HTTP caching directives, cache hierarchies, resolving HTTP/1.0 and HTTP/1.1 directives, etc. Where is a 96 page $39.99 O'Reilly book when you need one?
