0

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

/set/test_9_0/data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAEAAAABACAYAAACqaXHeAAAAtklEQVR4Xu3VwRHCMBTE0BgG

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.

1 Answer 1

0

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

2
  • 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, 2012 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, 2012 at 23:13

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .