Sitecore lets you specify a page to use for ‘ItemNotFound’ errors in web.config, and it’s always good practice to have a pretty ‘page not found’ page:
<setting name="ItemNotFoundUrl" value="/404" />
However, Sitecore hasn’t always been the best for actually returning the right HTTP status code for the 404 page. It redirects (more on that later) your failed request to a specified page in Sitecore – but the serves that page correctly, including an HTTP 200 status. This is sad, as search engines don’t understand that the page actually hasn’t been found. Continue reading “Handling 404s in Sitecore”
A reminder to myself – there is a response header for SharePoint requests called the X-SharePointHealthScore. It indicates how stressed the server is with a score from zero (unstressed) to 10 (highly stressed). I first stumbled across it when debugging something in Fiddler, but others have written about it:
- Andrew Connell has a brief write up
- Mick Breeze dug into it with Reflector
- Michel Barneveld seems to have found it the same way as I did – but looks at how it is calculated. He also describes how to force SharePoint to return a given value, in case you need to test something (like how your client code handles a stressed server)
So how do we test the loadbalancer if we set it up in this fashion? Do we need to DDoS a WFE? There is a better way 😉 There is a registry setting that will override the Health Score and it will return the value from the registry.
Create a DWORD with the name ServerHealthScore in the following location: HKLMSOFTWAREMicrosoftShared ToolsWeb Server Extensions14.0WSS and give it the value you want.
So what’s it useful for? Well, the main things that strike me would be:
- Server Monitoring – Pretty obvious, really.
- Client Applications – Can warn or take corrective actions if the server is loaded and may implement throttling.
- Client Side scripts – Similar to above, though I haven’t yet been able to figure out who you’d get this value in the Client Object Model. I’m assuming there is a way to get the response headers in the Client Object Model – otherwise you may have to use normal XMLHttpRequests if you want to see the response headers.