Sometimes we have extremely long query strings because we’re using a long list of items (e.g. zip codes and this breaks the browser URL length limits. It would be nice if the UI had a setting to say use Post all the time. Seems like the API supports post but the UI does not have a setting to indicate that the UI should use it (or at least we have not found one).
Hi @hockey_dave
How long are your queries, meaning amount of characters? And which error do you see?
I think the reason GET is used, is to make it really easy to share - just copy/paste the URL.
1 Like
The Url is 9010 characters. Metabase responds with: We’re experiencing server issues. Try refreshing the page after waiting a minute or two. Also: 414 Request-URI Too Large
I get why Metabase prefers Get over Post (i.e. sharing) but it would be good to have the option to use Post when required.
@hockey_dave
Interesting. Do you have a reverse proxy or using Jetty directly?
Do you see anything in the Metabase log - either first respond or after refresh?
You should be fine with that amount of characters - but that’s based on standards, not if Metabase is handling anything wrong.
https://stackoverflow.com/questions/417142/what-is-the-maximum-length-of-a-url-in-different-browsers
Thanks for the hints. We’ll take a look at our Nginx settings. It could be that is truncating it.
I have this issue while embedding dashboards. What is the solution for this using metabase as a single jar? I suppose I need to configure Jetty server which is used in standalone app, but have no success so far to find where the jetty config is placed inside the jar file
@buckelieg What specific error are you seeing and where is it coming from?
You would need to make your own build of Metabase to change the Jetty defaults.
The Jetty configuration is done here: https://github.com/metabase/metabase/blob/master/src/metabase/server.clj
The error is:
Bad Message 414
reason: URI Too long
Lacking having this and this and the dashboard embedding does not allow an optional parameters I have implemented custom filter bar which uses to fill in all parameters as a string, then th goes tokenized on the server and placed as SRC attr to iframe which in turn replies to me we that error.
With some combinations of the filter parameters Iam receiving another error:
Bad Message 431
reason: Request Header Fields Too Large
@buckelieg
It sounds like you’re sending a massive string - how long is it?
But is the error coming from Jetty or a proxy?
The 431 error should be changeable once this PR gets merged:
https://github.com/metabase/metabase/pull/12082
EDIT: Actually it seems like the PR will take care of both errors.
Yes it is.
String parameters could be VERY VERY long since it contains enumerated values concatenated by particular delimiter i.e. - for dropdown list values.
Filter bar could have any number of dropdown lists with dozens of options in each.
And whenever user selects no values from that lists (that are considered optional) All values gets send as the selected filter values to embeddable dashboard.
So for every filter I create a concatenated string which gets composed and signed on the server (the handler uses POST method to avoid 414 error) and that signed token is VERY long. It can be considered of any length.
On the metabase side I have spectially written SQL queries that parses delimited string and use it in IN-clause in optional parameters of each card.
The parameters for that filterbar are retrieved from special card with predefined name (having custom SQL which forms a parameter set with predefined format) through metabase API and gathered on the server side.
All of this things will be unnecessary if this issue could be implemented. 
No proxy is used in my case - so the URL does not get modified besides my code.
Any ETA on that PR? 
For metabase, you may set environment property- MB_JETTY_REQUEST_HEADER_SIZE. I set following in my start up script for metabase.
export MB_JETTY_REQUEST_HEADER_SIZE=100000
If you have another proxy server, you may need to set corresponding property on that too.
@tachniki I would recommend slowly increasing the value until you don’t have errors - like 16384 - instead of setting a very high value. There are some security concerns about allowing very large headers.
For reference:
https://www.metabase.com/docs/latest/operations-guide/environment-variables.html#mb_jetty_request_header_size