What version of Find are you running?

Do you see any more details in terms of erros in console and/or network tab upon save?

Hi Mari

We are using Epi find V 13.2.9

Consol error does not give anything tangible

Failed to load resource: the server responded with a status of 431 ()
dojo.js:2
_3ee
message: "Unable to load /episerver/Find/proxy/_admin/unifiedweights/ status: 431"
response: {url: "/episerver/Find/proxy/_admin/unifiedweights/", options: TMP, xhr: XMLHttpRequest, loaded: 54, getHeader: ƒ, …}
responseText: "The custom error module does not recognize this error."
status: 431
xhr: XMLHttpRequest {ajaxData: null, onreadystatechange: null, readyState: 4, timeout: 0, withCredentials: false, …}
stack: "Error: Unable to load /episerver/Find/proxy/_admin/unifiedweights/ status: 431↵ at new _3ee (/episerver/Find/ClientResources/dojo.js:2:105837)↵ at _3c8._57a [as handleResponse] (/episerver/Find/ClientResources/dojo.js:2:148211)↵ at XMLHttpRequest._586 (/episerver/Find/ClientResources/dojo.js:2:148490)"
__proto__: Error

Hi Naveed,

The 431 status would imply that the request headers were too large. Do you have a large amount of data stored in cookies which is being sent with the request?

Hi Paul - This error is on Epi Find interface on "Configure" screen. I can not change the default Weight options.

I can get results from find index and everything works from code.

Hi Naveed,

I can recreate the error by using a chrome add-on to modify the request headers to increase their size. Once they get above a certain size, I start seeing the error, though only on that request. The difference seems to be that the request to save the weights appears to be proxied to the Find service, whereas others either go no further than the CMS or result in a separately constructed HTTP request to the Find service. The proxied request seems to retain the majority of the headers passed to it and I'm guessing the Find service has a lower value for the max header size allowed which is why the error crops up on that request alone. As I said in my previous comment, I think the most likely cause for the excessive header size is going to be cookies so, if you want to fix the issue, I suspect you'll need to take a look at how you can reduce the amount of data being persisted in cookies. If you're using Identity, it would be worth looking at the amount of data you're storing as claims as they typically get persisted in an encrypted cookie.

Nice one, Paul! 💪🏻👍🏻

Hi Paul

Sorry I did not understand initially because we are not storing a lot of identity-related data or any website-related data in cookies but Yes I have identified the problem and it is related to the size of request reader. 

It seems like our Personalization provider (not Episerver) is creating a lot of cookies and these cookies information is included with request header.