We have a Salesforce Site set up and a URL rewriting class that takes the URL and transforms it to add parameters. This should be pretty straight forward.
a user goes to
siteurl.comis our site’s domain
vfpageis the visualforce page
paramis the value that the url rewriter looks at to determine what to display
This works perfectly in nearly all situations. When looking at the debug logs, I can see the url rewrite class being called, and the user is displayed the correct content.
http://siteurl.com/vfpage/bricksshows content based on the ‘bricks’ parameter
There does seem to be an issue though. When the parameter is a number, and that number is an http status code, the url rewrite class is never called. (as observed in the debug logs)
http://siteurl.com/vfpage/100does not result in the url rewrite class being called, and the user is shown the 404 not found page.
I’ve tested this with a range of numbers, and the only common thing I can see is that it closely (but not perfectly) aligns with http status codes.
e.g. using 99 works as expected (url rewrite class is called), but 100 fails (url rewrite class is not called). 401 fails, but 420 passes.
Has anyone else seen this behaviour? Does anyone have an environment with a url rewriting class that can test/verify this?
I’m trying to work out if this is a mistake we’ve made, or whether Salesforce has a bug.
From the documentation
User-friendly URLs must be distinct from Salesforce URLs. URLs with a
three-character entity prefix or a 15- or 18-character ID are not
Under Restricted Characters section we can see that Salesforce style urls are not rewritten. Http status codes probably matching with Salesforce’s own urls either as a http status code or an object prefix. So no, this is not a problem on your implementation. And also it’s not a bug, it’s a feature.