BadMagicNumber

Omri Gazitt (whos blog is a
typical Microsoft one - very useful!) today posted how to (partially) href="http://www.gazitt.com/OhmBlog/permalink.aspx/f850bebf-97b0-4ebb-99ce-0
72bdcb4422f">get rid of the dreaded “Access Forbidden: Too many users are
connected Internet Information Service” error on IIS.

I've run into this error at the most inopportune of times - once we were
demoing our app (running on a notebook, with IIS in front of JRun 4). We
were plugged into the client's network, and they were mucking around with it
while we were demoing. Of course, We start having bloody “Access Forbidden”
errors, and have to try and explain WTF is going on (and why it's not a
problem on the real system) to a whole lot of people who were much more
interested in the app for what it did than the technology. Very
embarrassing!

Charles Miller had an interesting post about
spam he is recieving that is designed to get through Bayesian filtering.

I am of the opinion that Bayesian filtering will eventually be only one of a range of filters which people will need to
deploy against spam. I'm optimistic that combinations of text filtering algorithms (including, but not only
Bayesian alogorithms) can continue to be effective for some time.

I think other filters are needed, though. For instance, in the spam that Charles recieved many words (designed to
fool Bayesian filtering) were styled to be invisible. This used to be an old search-engine spamming technique, but now
Google detectes that, and actually uses the stylistic structure of the web page (ie - the appearance) during its analysis.
I can't think of any reason why mail filters can't do the same thing.

(Disclaimer: I've written an open source package for Bayesian filtering in Java)

Many web applications depend require cache control for pages, especially if
they involve user logons or time-dependant data.

Usually this is achieved with HTTP headers - something like (in JSP):

response.setHeader(”Cache-Control”, “no-cache”);
response.setHeader(”Expires”,”Tue, 30 May 1980 14:00:41 GMT”);

An alternative, which usually work well is to require your site to be run
under HTTPS. In theroy, this seems ideal, since it provides security as well
as cache control.

However, beware of the impact of things like reverse-proxies. Many companies
are installing reverse proxies in front of their web hosting machines
to do request filtering in order to provide some
protection against SQL injection & XSS attacks on their websites. This is a
really good idea, but there can be some unexpected impacts.

One I didn't expect was the impact on caching. Because the proxy needs to
inspect the request, it decrypts it, then forwards the request as a HTTP
request to the server. Many vendors list this as a feature, because it
offloads some processing requirements tot he proxy-box, instead of the
webserver. The catch comes if you don't have explict cache control in your
pages AND the reverse proxy is a caching reverse proxy. In this case the
proxy may return the cached content to the user, which is NOT WHAT YOU WANT!

Another complicating factor is that some reverse proxies forward the original HTTP
1.1 requests to the server as HTTP 1.0, and seem to ignore HTTP 1.1 headers
that are returned. This can bite you if you only use the “Cache-Control”
(HTTP 1.1 only) header.

Lesson:
Always provide explict cache control AND expiry headers, and never rely on
HTTPS to control caching for you.