> X-Http-Method-Override - used to set a method that couldn't be set as the real method of the request for some reason, usually a client or networking limitation. Mostly a bad idea nowadays, but still popular & supported by quite a few frameworks.
This is popular and supported because it serves a real need. A GET request shoves all the query parameters into the URL, and if that gets long enough, it will be truncated somewhere and the results will be wrong or you'll just get an error.
By instead sending a POST request, where all the parameters go in the body and don't get truncated, but using the header to tell the server to treat it as a GET request, you solve those bugs almost seamlessly.
The drawback is that you don't have a bookmarkable/linkable URL - some of the semantics are lost. But that can be worked around afterword with an id or hash of a previous request's parameters that tells the server "give me the same results as if I had entered all the query parameters that were entered in this previous request".
This is popular and supported because it serves a real need. A GET request shoves all the query parameters into the URL, and if that gets long enough, it will be truncated somewhere and the results will be wrong or you'll just get an error.
By instead sending a POST request, where all the parameters go in the body and don't get truncated, but using the header to tell the server to treat it as a GET request, you solve those bugs almost seamlessly.
The drawback is that you don't have a bookmarkable/linkable URL - some of the semantics are lost. But that can be worked around afterword with an id or hash of a previous request's parameters that tells the server "give me the same results as if I had entered all the query parameters that were entered in this previous request".
It's not optimal, but pragmatic.