Affiliate marketing is undead
Dear Internet marketers: affiliate marketing schemes that pay money are dead, killed by spammers. Please get over it and find a marketing technique that doesn't cause spam and attract spammers. (And if you are actually a spammer hiding behind 'affiliates', sorry, no one believes that any more.)
Affiliate marketing pays people for traffic. When people are being paid for traffic, spamming becomes the most cost effective way of generating it. So people spam. Anyone who opens their eyes can see this all over the Internet.
On today's Internet, spam is the inevitable consequence of 'affiliate marketing' schemes. There is a word for people who knowingly do things that cause spam: in many eyes, it is 'spammer'. (Or worse, for people who are trying to profit from spam without catching the blame for it.)
The other inevitable consequence is a bad reputation, because you can't throw a stone at spam without turning up (claimed) affiliate marketing or 'pay per click' programs. Consider that my referrer spammers, my comment spammers, and even the spam blogs I found are all doing it.
Affiliate marketing should be dead. But people prefer not to see this or believe their scheme will be an exception. As a result, affiliate marketing schemes lurch around the Internet, shedding spam everywhere they go, dead but still moving. In short, undead.
Unfortunately, I believe that this means that Google AdSense is probably doomed. And as the spam blogs I found demonstrate, spammers are already exploiting it. (Google can work to stop spammers, but there are lots more would-be spammers than there are Google people working to stop it.)
(If you don't 'pay' affiliates in money but instead use moderate discounts of not very liquid merchandise, you may be able to survive. See Amazon.)
The problem with If-Modified-Since as a timestamp
If-Modified-Since header in HTTP requests is used as one way of
doing 'conditional GET' requests, where the web server can give you a
nice bandwidth-saving '304' response if the URL hasn't changed since
the version you already have. In theory the header has an arbitrary
timestamp and the server will 304 the request unless the page has
changed since that time.
In practice, the HTTP RFC strongly recommends that clients treat the
value as a magic cookie, just repeating the value the server last told
them. Unfortunately, not everyone does this. This is bad, because it
is very difficult for the server to use
If-Modified-Since as a real
If-Modified-Since as a timestamp, your last modified time
has to go forward any time a change is made. Or, to put it another
way, you have to guarantee that your last modified times will always
go forward. This sounds nice in theory but is extraordinarily
difficult in practice, even for static web pages.
For example, here's a bunch of things you have to consider for static pages on Apache on Unix:
- did I rename the old 'page.bak' to 'page.html'?
- did I rename a higher-level directory to flip to another version of an entire section?
- did I change rules in a
.htaccessfile that affects the page?
- did I modify the web server's configuration files, ditto?
(Even if Apache made all these checks, it still couldn't guarantee that I hadn't just had to flip a backup server with a not yet fully up to date copy of the website into production when my main server exploded.)
Dynamic web pages have it worse, in part for the reasons in Pitfalls in generating Last-Modified; they have more moving pieces and the moving pieces don't always come with change times attached.
Doing this right requires the application generating dynamic pages to find out any time anything affecting those pages changes. There are 'total control' applications like that out there, but not very many, as such total control has significant costs (for a start, everything has to go through the application).
DWiki is honest about not being able to make its own timestamps always
run forward, and thus requires strict
If-Modified-Since matching as
a minimum. To do otherwise would run the risk of erroneous 304s,
which in my opinion are much more serious than some extra bandwidth
(People with more constrained bandwidth may feel otherwise. But in
that case they should fix their clients to use