A critical vulnerability was discovered in React Server Components (Next.js). Our systems remain protected but we advise to update packages to newest version. Learn More

Magnus Rahl
Feb 21, 2011
  4065
(1 votes)

Search Service problem for users with many groups

The new EPiServer Full Text Search is fully integrated into the RelatePlus package. All content created is added to the search index, including the content’s access rights. That means access control filtering can be done by the indexing service before returning search result. Very convenient for paging of results etc. when you know you can display all the results returned.

Unexpected limitations

Suddenly some of our users didn’t get any search results back. Digging in the log showed several errors and after repeating the queries I could see that they returned 404 not found even though other queries worked perfectly.

After further troubleshooting it was evident that it was the length of the query (which is passed to the REST service in the query string) that was the culprit. Since the user’s groups are passed to the indexing service, a user with many groups performing a search will result in a very long query string.

Since, at least in the RelatePlus standard templates, users are added to a new group for each Club they join the query can grow large very fast.  If you have built your community based on the RelatePlus templates you could have users who are unable to perform searches.

Solution

ASP.NET has a setting for the maximum allowed length of the QueryString (note that this is a server to server call, so no browsers are involved, but they also have limitations). This is set in the configuration / system.webServer / security / requestFiltering / requestLimits elements in the maxQueryString attribute. There is also a maxUrl attribute but they are independent (maxUrl is everything up to the query, but not including it). De default value for maxQueryString if it is not set is 2048, which was the limit my users’ queries hit. I simply increased this value like so:

<system.webServer>
  <security>
    <requestFiltering>
      <requestLimits maxQueryString="16384" />
    </requestFiltering>
  </security>
</system.webServer>
Feb 21, 2011

Comments

per
per Nov 23, 2011 05:38 PM

And if you are running ASP.NET 4 you also need to set the new maxQueryStringLength on the httpRuntime element.

Please login to comment.
Latest blogs
Looking back at Optimizely in 2025

Explore Optimizely's architectural shift in 2025, which removed coordination cost through a unified execution loop. Learn how agentic Opal AI and...

Andy Blyth | Dec 17, 2025 |

Cleaning Up Content Graph Webhooks in PaaS CMS: Scheduled Job

The Problem Bit of a niche issue, but we are building a headless solution where the presentation layer is hosted on Netlify, when in a regular...

Minesh Shah (Netcel) | Dec 17, 2025

A day in the life of an Optimizely OMVP - OptiGraphExtensions v2.0: Enhanced Search Control with Language Support and Synonym Slots

Supercharge your Optimizely Graph search experience with powerful new features for multilingual sites and fine-grained search tuning. As search...

Graham Carr | Dec 16, 2025

A day in the life of an Optimizely OMVP - Optimizely Opal: Specialized Agents, Workflows, and Tools Explained

The AI landscape in digital experience platforms has shifted dramatically. At Opticon 2025, Optimizely unveiled the next evolution of Optimizely Op...

Graham Carr | Dec 16, 2025

Optimizely CMS - Learning by Doing: EP09 - Create Hero, Breadcrumb's and Integrate SEO : Demo

  Episode 9  is Live!! The latest installment of my  Learning by Doing: Build Series  on  Optimizely Episode 9 CMS 12  is now available on YouTube!...

Ratish | Dec 15, 2025 |

Building simple Opal tools for product search and content creation

Optimizely Opal tools make it easy for AI agents to call your APIs – in this post we’ll build a small ASP.NET host that exposes two of them: one fo...

Pär Wissmark | Dec 13, 2025 |