Your achievements

Level 1

0% to

Level 2

Tip /
Sign in

Sign in to Community

to gain points, level up, and earn exciting badges like the new
Bedrock Mission!

Learn more

View all

Sign in to view all badges


Issue with url.infinity.json


Level 2

When I hit the below url  http://localhost:4502/content/geometrixx-outdoors/en.infinity.json, I am getting the following response


instead of full json response. I want the response like the below url 



Please help me in this, how can I go with this

1 Accepted Solution


Correct answer by
Level 2

Thanks. but why it is not showed full details of child pages information instead of showing 


View solution in original post

0 Replies


Level 10

There is no issue here. THis is the expected result based on the URL you specified.  I am seeing it too. 

See the JSON heading in the AEM Topic:


Correct answer by
Level 2

Thanks. but why it is not showed full details of child pages information instead of showing 



Level 9


Infinity is a special selector handle by defaultSlingServlet. If it works the way you want to, there will be serious consequences. Let's see if someone wants to render all the content (http://localhost:4502/content.infinity.json ) in json response.



Level 2

Thanks to all. In OSGI configuration, JSON Max results option is available for default sling servlet. With that option we can return maximum number of results.




Yes, as mentioned, Json max result is use to limit the rendering.When this limit is exceeded the rendering will be collapsed. The default value for Sling within AEM is 200.


Thanks and Regards

Kautuk Sahni


Level 2

Are you getting a "300 Multiple Choices" response code? That's what I get when I see a list of urls like this on a related issue I am having. I am running and still have this issue. If I figure it out, I will let you know.


Level 2

It seems that if a page is returning more than 200 resources when using the infinity selector, then the Apache Sling GET Servlet will return the list of paths indicating selectors 0 through 5 instead of the json nodes. This seems to happen on pages that have a lot of content nodes.


You can fix this by setting the "Json Max Results" 200 value to a higher number.

I read somewhere that a lower number here is to protect against DOS attacks by repeat requests to pages with the infinity selector....

Generally I am thinking that our code should not make .infinity calls, otherwise it will be subject to this limit. I am exploring the AEM OOTB code because the cut/paste operation in the TouchUI makes a call to infinity.json and it causes cut/paste to fail if the page has more than 200 resources.


I'll report more when I know it.




Screen Shot 2020-07-13 at 11.36.57 AM.png




Level 2


Bug Scope

Affected Instances

  • LocalHost-Author
  • Staging-Author
  • Production-Author

The problem affects all author instances.
It appears on any page that contains more than 200 resources. A resource is defined as a node. A node consists of components and elements that make up the component.

The LSA Homepage is the page that helped discover this bug, but in actuality, any page in the author instance that has over 200 resources will experience failing cut/paste operations.


Debugging in browser shows that a paste operation preceded by a cut operation makes a request to:

https://<AEM instance>/content/michigan-lsa/en/jcr:content/gridpar.infinity.json


which is returning the HTTP Status Code: 300 Multiple Choices.

300 Response
JSON Response


This is not the desired response. The code making this call is expecting a JSON representation of the page. Here is an example:



The reason this happens is because the Apache Sling DefaultGetServlet has configured a "JSON Max results" value of 200 resources. The LSA homepage has more than 200 resources available to be returned, therefore the servlet detects this and uses the 300 code to inform the client that there are different selectors other than "infinity" that can be used.

Interestingly, the copy/paste operation does not use the infinity selector, as shown here:


Shown in the image above are all the places in our project code that reference


Also indicated is that our custom code overrides a value of 1,000 set by Adobe's code in:


This article from Adobe indicates that the default is 200. AEM Explanation for JSON Max Results. It is likely that this article is out of date and that at some point Adobe updated their code to use 1,000.

There is a DayCare ticket for this: DayCare Ticket


The Apache Sling DefaultGetServlet has configured a "JSON Max results" value of 200. This limit can be increased to a larger number.

Apache-Sling-DefaultGetServlet (1).png

The following screenshot shows that the AEM Dispatcher is configured specifically for publish instances, but not for author instances, to deny the infinity selector.


Examining the code base shows there is not denial of the use of the infinity selector on the author instances. This is because it is needed on author for operations [case in point: cut/paste]. The comment shown in the dispatcher image indicates that the infinity selector is denied in order to prevent DOS attacks.

In the same vein of thinking, the Apache Sling DefaultGetServlet has this "JSON Max results" configuration for a similar reason. To help prevent DOS. It is important to keep in mind that this servlet exists on both the author and publisher instances. Therefore it makes sense that a limit option is available. The author instance is protected behind password accounts, therefore if we assume that our authors are responsible, non-malicious users, we can argue that the 200 limit can be increased on the author instance. It is still advisable to use a limit because without it, as the reference article above explains, a .json request on the root of the instance can cause a json dump for the entire repository which would likely degrade overall performance of the instance. It is not known if this would cause a crash or not.




Code Change
Modified runmodes for STAGE and PROD to use 1,000 instead of 200 for the json.maximumresults on the Apache Sling DefaultGetServlet config.


Root Cause
The following commits were done as part of a passthrough to update the security of OSGI configurations. It has been identified that the reference documentation misleadingly implied that the json.maximumresults should be set to 200 and DayCare and default AEM configurations contradict this as they specify the configuration to be set to 1000.



The code change setting this number back to 1,000 was essentially unneeded as it would have been just as valid to delete the special runmode overrides. Doing so would have the


configuration take effect.


I reviewed this configuration and it was decided to set this value explicitly in our code rather than utilize the AEM configuration because we are approaching security from the perspective of the security checklist and not from the OOTB configurations. Therefore, by explicitly configuring these limits in our runmodes, we have a committed record that we observed the security checklists, [with notes explaining why we deviated when necessary, as in this case].