Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I use a non caching Nginx proxy to map some path on port 80 to an application specific http server on another port.

That works quite well for almost all URLs, however long URLs containing Base64 encoded data are truncated early. They are truncated at very shot lengths, vastly before the large_client_header_buffers limit. For example, my application server recieve URLs like


The original URL was running for about 1-2 kbytes. It seems that the original URL continued with %2B in this example case right after the cut location. Why does Nginx cut the URL at this location, and how to prevent that? I still need the path translation, as the application will always serve some services at root path level.

share|improve this question

Might be affected by proxy_headers_hash_max_size . The default is 512, so could be clipping the request header info.

share|improve this answer
I just use the proxy as pass thru without a cache. So computing a hash at all would be a bug a think, and restrict the data iself to the hash length would be even buggier.. – dronus Mar 18 '12 at 22:58
@dronus It was just a guess (as I didn't take anytime to try to reproduce your behavior for myself). The caching and proxing is all part of the same nginx module, so it seems possible that even if caching isn't enabled, it still goes through some of the same code-paths when parsing and proxying the headers. – dbenhur Mar 18 '12 at 23:13

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.