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.

e.g. a user goes to http://siteurl.com/vfpage/param where

  • siteurl.com is our site's domain
  • vfpage is the visualforce page
  • param is 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.

i.e. http://siteurl.com/vfpage/bricks shows 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)

i.e. http://siteurl.com/vfpage/100 does 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.

  • I think, you can use url encoding before sending the number Jan 18, 2017 at 3:28
  • @SantanuBoral This is more to do with using the UrlRewriter interface rather than any url encoding. Also, url encoding '400' would still be '400'
    – Nick C
    Jan 18, 2017 at 3:59
  • Can you check if you url rewriter gets called for 002, 003 etc?
    – tugce
    Jan 20, 2017 at 7:48
  • @tugce The url rewriter does not get called for 001, 002, ..., 008. It does get called for 000 and 009, but then not called for 010, 011...
    – Nick C
    Jan 21, 2017 at 2:26

1 Answer 1


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 rewritten.

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.

  • Nice one. In short, RTFM! :)
    – Nick C
    Jan 21, 2017 at 22:41
  • One correction: That is NOT a feature. Feb 14 at 14:01
  • Technically it is documented so at least we know it is working as designed...
    – tugce
    Feb 15 at 20:46

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .