DEV Community

Jeremy Davis
Jeremy Davis

Posted on • Originally published at blog.jermdavis.dev on

2 1

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>
Enter fullscreen mode Exit fullscreen mode

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…

AWS Security LIVE!

Tune in for AWS Security LIVE!

Join AWS Security LIVE! for expert insights and actionable tips to protect your organization and keep security teams prepared.

Learn More

Top comments (0)

Sentry image

See why 4M developers consider Sentry, “not bad.”

Fixing code doesn’t have to be the worst part of your day. Learn how Sentry can help.

Learn more

👋 Kindness is contagious

Engage with a sea of insights in this enlightening article, highly esteemed within the encouraging DEV Community. Programmers of every skill level are invited to participate and enrich our shared knowledge.

A simple "thank you" can uplift someone's spirits. Express your appreciation in the comments section!

On DEV, sharing knowledge smooths our journey and strengthens our community bonds. Found this useful? A brief thank you to the author can mean a lot.

Okay