Moved styles to setup.css

The 404 page now omits the space list, and now looks a bit more like Confluence. This should speed up processing time of false requests.

Unfortunately this change didn't make it into 2.8.2. I'm rescheduling it for the next version.

Hi Peter,

We are working on a new 404 page that will omit the space list

This issue was raised as a result of our 404's with (then) over 100 Spaces causing a severe performance drain on the system (v2.5.4). Atlassian gave us the attahced 404.vm to use and it's worked great. Any particular reason that couldn't just be made the standard?

Just curious....

When the accept headers don't explicitly state text/html as an acceptable return type, the bot will get a simple 404.

We're going to be doing multiple things to reduce this problem, the accept header processing is only a part of it, and a good part I think.

Christopher,

Relying on clients to send or not to send some headers isn't very good. We get a ton of bogus requests from bots like this one:

88.161.215.231 - - [02/Jun/2008:14:15:34 -0700] "GET /_vti_bin/owssvr.dll?UL=1&ACT=4&BUILD=6551&STRMVER=4&CAPREQ=0 HTTP/1.1" 404 198592

I really don't want to waste a lot of resources in order to serve this bot with a fancy 404 page.

The facy 404 page should only be served for PageAware and SpaceAware actions. If a client can't even get the action part of the URI right, then it's most likely some bogus request that doesn't deserve to be served with a sophisticated 404 page.

"...serve a different 404 page for different resources..."

If so, don't forget about *.js and *.css – those two bit the Clickr theme jointly (two scriptaculous libs were in the "wrong" place). The 404 responses went undetected until a user complained of overall slowness of their space on a server with 1,500+ spaces. When I investigated, I saw the two 404 responses, each listing out all the spaces with descriptions – totaling ~3Mb per page load. Ouch.

I quickly mod'd the 404 error page template to rip out the extra bulk. One concern I still have though is that the java actions that back the Velocity template are still expending extra cycles to create the beans that back the template. I.E. the template modification will help from a bandwidth point of view for the user, but 404 actions may still be adding load to the server.

-Timo

I've been experimenting with some other arrangments as well. For instance we can use the "Accept" header sent by Mozilla browsers to determine whether to render the more expensive 404 or not. When Gecko based browsers ask for embedded/included resources they send an "Accept" header tailored to the type of resource it expects to embed e.g. image/* for <img src=""> and text/javascript for <script.. etc. We could just send cheap 404s in these cases as well.

Need some further investigation into Internet Explorer's behaviour.

wikis.sun.com just went through an issue where a missing image caused our connection pool to start running out of db connections, because the 404 requests where holding on the db connections for too long (in some cases for several minutes due to db backlog).

Once the image was in place, things went back to normal.

Plz change the 404 page behavior. I like Scott's idea about serving different 404 page for different resources. Make all the PageAware actions return the fancy 404 page, otherwise return something simple.

Thanks.