The CQ resource resolver interprets the last work after "." as extention which is actualy the type of response, request is expecting (content type) so if you use "foobar" or something which not a valid content type that server can response it will through you same exception what you are getting. you can validate error message on same error page.
All other words after last extension and before the main resource path are considered as selectors which is relative to current requested resource which is resolved by resource resolver by taking the same name and if doesn't find it then it will map to best near match as per this http://dev.day.com/docs/en/cq/current/developing/the_basics.html#Sling Request Processing
If you want to resolver any custom extension like .foo (not selectors) through resource resolver you have to customize the resource resolver mapping logic but i am not 100% sure that you can do this (i did not try this requirement.)
Couple of reference i can suggest to look at
I hope above helps you to proceed.
there is no out of box functionality to support other extensions except .html what you can do that modify get.jsp by copying it into you apps directory . otherwise you can use selectors but it should support .html eventually like a.foobar.html etc.
Bix - are you sure that the sling:resourceType of /content/us/page1 is set to us/components/all ? My guess, based on your description (and that this is the CQ forum) is that /content/us/page1 is actually a cq:Page, without a sling:resourceType property. It has a child node, named jcr:content whose sling:resourceType property is set to us/components/all.
GET.jsp certainly will handle all extensions (at least those for which a specific script is not defined).
I tried this earlier for one of my implementation expecting GET.jsp will handle all the request but i came to conclusion that resolver only respect known MIME type like json, html, xml, js etc... and transfer request to GET.jsp and if corresponding custom selector is not available as scriptlet or not known MIME type then it does not respect (Does not resolve to GET.jsp) for examle "mypage.foo" or "mypage.test", not sure if i am missing anything?
By default cq resolver respond to .json, .xml, and .html for existing resource as far as i know.
I really don't think what you are saying is accurate.
Here's a really simple way to test this:
* Create a node whose sling:resourceType is testing/extension-test.
* Create a file at /apps/testing/extension-test/GET.jsp with this content:
Extension is <%= slingRequest.getRequestPathInfo().getExtension() %>.
* Request the node with various extensions as see the extension output.
I uploaded a package with this content in it which you can download from https://workspaces.acrobat.com/?d=0C5FCyOXoYwUIOZKJqSYEA.
There is absolutely nothing in the Sling Resource Resolver which restricts the set of extensions you can use.
Hi Justin, thanks for the response. You are correct in your description - I meant to refer to the jcr:content's sling:resourceType property.
It turns out that there is an article on how to do this - I found this when searching for something else: http://helpx.adobe.com/cq/kb/CQ53HowToAddACustomPageExtension.html
Special shout out to Gurpreet from Support for helping me with instructions. After inspecting the Page component render scripts, I now understand why the issue was occurring.