We have come across an issue with the cms search, where due to the presence of many languages and roles in our website, the length of the search request becomes too long for the average server and thus leads to malfunction.

As you know, the CMS frontend communicates via GET requests with a WCF Service (the IndexingService) that is hosted in the same web as the CMS itself. In these requests, the cms transmits the search string as well as which cultures should be searched and which permissions are available - along with additional metadata. The different parts that we have noticed in the url are the following:

• The host
• Search string
• User ACLs
• Search cultures
• Additional request info

An example query looks as follows:

https://my.host.com/IndexingService/IndexingService.svc/search/?q=((EPISERVER_SEARCH_DEFAULT%3A(test*))+OR+(EPISERVER_SEARCH_TITLE%3A(%22test%5C*%22%5E5)))+AND+(EPISERVER_SEARCH_VIRTUALPATH%3A(53f936c9%5C-9b23%5C-4ea3%5C-97b2%5C-61c538ad07c9*))+AND+(EPISERVER_SEARCH_TYPE%3A(%22EPiServer.Core.PageData%2CEPiServer%22))+AND+(EPISERVER_SEARCH_ACL%3A(G%5C%3Amy-custom-role-name))+AND+(EPISERVER_SEARCH_CULTURE%3A(en))&namedindexes=&offset=0&limit=50&format=xml&accesskey=local

This is pretty much a minimum request, but already has 473 characters.

On our websites we have around 15 cultures enabled and backend users usually have around 5 roles, but some are going up to 15 roles. This leads to a very long GET-request url, as the ACL and CULTURE parts are repeated for every culture and every role, and eventually we easily reach request lengths of 3-4k characters. That is a problem with many servers unless you explicitly extend the limits (if you can).

How could this be avoided?

1. Shorten the parameter names – in this way we would reach more than 2k characters much later
2. Use a POST request – No limits here
3. Try to reduce the amount of roles (unfortunately we have very fine-grained permission requirements to fulfill here)

Of course there can be other ideas as well, e.g. not using a WCF service at all.

On our side we have currently solved this by allowing much longer request urls, but a solution that doesn’t require this would be much appreciated.