We recently had to upgrade one of our client’s Sitecore website from version 8.2 to 9.1. During the upgrade we noticed that a POST request that was being used for one of the search components stopped working. The following error was being written to the Sitecore logs:
“Error: Invalid URI: The Uri string is too long.
The remote server returned an error: (414) Request-URI Too Long”
Looking at the configurations for SItecore 8.2 we noticed that Solr’s default request was set to POST by using a Sitecore support package as POST requests were not officially supported for that version of Sitecore. They were using the support package because they faced the same issue of the request size being too large for a GET request. And, this support package no longer seemed to work with version 9.1.
After looking around online I found articles pointing to a setting “ContentSearch.Solr.SendPostRequests” in the configuration file “C:\inetpub\wwwroot\trc91.local\App_Config\Sitecore\ContentSearch\Sitecore.ContentSearch.Solr.DefaultIndexConfiguration.config” and setting the value to true, should enable POST requests on Solr. Unfortunately, this didn’t work as we noticed that the search query was still being sent as a GET request. So, it seemed to have been working only for version 9.0 and not 9.1 (I have not tested this on 9.0).
Therefore, our next step was to reach out to Sitecore Support and they confirmed that the setting mentioned above doesn’t work and they have no plans of fixing it in the near future.
Instead, they gave us a workaround, to change the “requestHeaderSIze” attribute value to a higher value in the following file on your Solr server “[solr]/server/etc” (we set the value to 29000). Setting this value will allow Solr to support larger sizes for GET requests. It should look like this:
<Set name=”requestHeaderSize”><Property name=”solr.jetty.request.header.size” default=”29000″ /></Set>
We tried this workaround and we could confirm that the search component started working again. I hope this blog will help other Sitecore developers who might face a similar issue.