Why are my pages under /services/ broken?

This is one of those issues where I feel like I should have worked it out faster than I did. Computers are relentlessly logical. If you tell them to ignore something, they're going to ignore it, even if that does confuse your content editors...

I got a bug report recently, from a user complaining that they had set up a tree of content but after publishing, all they got was a 404. It was one of those bug reports that bounced around a few people before landing in my inbox – and it looked odd.

The content the user described did exist (a whole tree of pages under /services/) and it had indeed been published. The content worked fine on my development instance. But when viewed on the QA or UAT instances of the site, it did indeed return a 404. But not the styled 404 page you would get if you typed in a nonsense url – a completely plain page which said nothing but "404" on it:

Clearly something was blocking that path. But what? It was something not present for a development instance, but present for QA and UAT. The QA instance was a single-server site running on our local network, but the UAT instance ran on the client's infrasructure. That difference in infrastructuretended to rule out the idea that it might be an over-zealous firewall or a proxy that was blocking certain path segments.

So I did a "find in files" search for the word "services", and trawled through the list of hits. Eventually, I found that my dev instance included a hit in ship.config.disabled and I had my Eureka moment.

Our dev instances included the config and code for Sitecore.Ship, but it was disabled as we never deployed to dev machines via our build and deploy automation. That config file includes the following line:

<?xml version="1.0"?>
<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/" xmlns:set="http://www.sitecore.net/xmlconfig/set/">
  <sitecore>
    <settings>
      <setting name="IgnoreUrlPrefixes" set:value="/services/|/sitecore/default.aspx|/trace.axd|/webresource.axd|/sitecore/shell/Controls/Rich Text Editor/Telerik.Web.UI.DialogHandler.aspx|/sitecore/shell/applications/content manager/telerik.web.ui.dialoghandler.aspx|/sitecore/shell/Controls/Rich Text Editor/Telerik.Web.UI.SpellCheckHandler.axd|/Telerik.Web.UI.WebResource.axd|/sitecore/admin/upgrade/|/layouts/testing" />
    </settings>
  </sitecore>
</configuration>

					

Ship exposes an API under the path /services/ and hence it tells Sitecore to ignore any requests made to that path, so that Ship's HTTP handler can take care of these requests.

So on machines like QA and UAT, where we were making automated deployments (and hence this config file was enabled) Ship was ensuring that Sitecore didn't process these requests – causing to serve up the 404 HTML page that had been set up.

So...

If you're deploying via Sitecore.Ship, stop and have a think about that default services URL. Does the owner of the site you're working on provide any services to people? Might they want to name a tree of content "Services"?

If so, remember to change your site's config to avoid a load of confusion...