Request header is too large

Hi all,

We are using brxm-14.5.0, have deployed to gcp kubernetes, we are using headless cms, we have our own UI and from there by using xpath search query (GET) i.e.

http://{domain}/cms/repository/?search-type=xpath&uuid=&text=&text-limit=1000&xpath={/jcr:root/content//element(*,hippo:document) some filter data}&xpath-limit=1000&sql=&sql-limit=1000

All search query(30kb) is part of GET call url. We are fetching large volume recods(GET api with 30kb search data), during this hit my cms pods were getting unresponsive for few minutes, we found below logs during investigations :

### IllegalArgumentException: Request header is too large
org.apache.coyote.http11.Http11InputBuffer.fill ( org/apache.coyote.http11/Http11InputBuffer.java:790 )

We want to know about the root cause, because above message belongs to 4xx bad request and due to this cms pods shouldn’t be killed/unresponsive, please help to understand the root problem.

Thanks,
Manish Kumar

Hello, are you using /cms/repository queries to get data for your front-end headless SPA? If yes this is completely wrong, you need to be using the Delivery API or the Content REST API. See APIs - Bloomreach Experience Manager (PaaS/Self-Hosted) - The Fast and Flexible Headless CMS

/cms/repository is a tool for developers and admins to query the repository, it should not be used to fetch data for a live website. Fix this issue first before anything else.

Hi @david, thanks for your reply,

Now we have used rest api having _query path and then passed with 30+kb data in serach field and this time also I faced ### IllegalArgumentException: Request header is too large, does this exception makes CMS unresponsive?

Thanks,
Manish Kumar

If that error is showing up in CMS logs, then it’s probably the default Tomcat setting restricting request header sizes. See maxHttpRequestHeaderSize here Apache Tomcat 8 Configuration Reference (8.5.100) - The HTTP Connector

It could also be coming from the ingress controller in GCP, they usually also have limits around this.

However a 30kb request is huge - what kind of query are you doing exactly? This is probably crippling the CMS if it’s some sort of unoptimized xpath query, so I’m not surprised if the pods become unresponsive.