It might be a stretch to call this "broken" but the wininet.h surely has omitted significant detail. These are the bit values officially defined for it:
#define NORMAL_CACHE_ENTRY 0x00000001
#define STICKY_CACHE_ENTRY 0x00000004
#define EDITED_CACHE_ENTRY 0x00000008
#define TRACK_OFFLINE_CACHE_ENTRY 0x00000010
#define TRACK_ONLINE_CACHE_ENTRY 0x00000020
#define SPARSE_CACHE_ENTRY 0x00010000
#define COOKIE_CACHE_ENTRY 0x00100000
#define URLHISTORY_CACHE_ENTRY 0x00200000
Problem is, if you call FindFirstUrlCacheEntryEx/FindNextUrlCacheEntryEx to enumerate the cache you'll find that there are several bits in use that aren't defined.
For one thing, bit 0 (NORMAL_CACHE_ENTRY) is always set, for every entry, so I assume an entry is "normal" when only that bit is set. The tech ref makes no mention what to make of composite types -- how can an entry rationally be "normal" and something else at the same time? For my purposes I masked bit 0 and then considered a 0 result to be "normal".
More, in my cache right now there are entries with the following [undefined] type values: 0x41, 0x45, 0x101, 0x1041, 0x1141, 0x2041, 0x3041 and 0x8041. This means there are 5 single-bit values that are left undefined by wininet.h:
I've noticed that Pragma: no-cache appears in the headers of all entries with CacheEntryType == 0x3041. Whether anything empirical can be inferred from this about type value 0x3041, I can't really say -- but it surely speaks to just how worthless Pragma: no-cache is! All items of this type are backed by a local file, and worse, every single one has expiry in the past! What the fuck? Talk about being thrown under a bus! Whether IE would actually use them may be another matter entirely, but the fact that they exist in cache and on disk surely makes it possible.
Nothing I've found online even mentions this short-fall of definition, most of it merely regurgitates what's found on MSDN... which is useful, not at all.