Any indications what's the issue here? With getting the logo_data for a tree view I get a bad gateway (502) error..
followed by a similar request that gives a 200 OK.
Solved
502 bad gateway indicium with logo_data
+16Best answer by Vincent Doppenberg
Hello Freddy,
The default request timeout on IIS is 110 seconds. We don’t really have a recommendation for this, because it depends on the application. But 110 seconds rarely leads to problems so that seems like a good value to suggest for now.
As for the proxy buffer sizes, I don’t have any suggestions for this without looking into it more. However, I would imagine that the default settings of nginx are good. This is not something that I would expect to need additional configuration.
This topic has been closed for comments
Hello Freddy,
If I would have to guess, I'd say that the request that resulted in the 502 status code was the first request to that application (sf/10288) and Indicium had to load the application model. This might have caused Indicium to go over the timeout that is configured on the reverse proxy, which I believe is nginx in your case.
Is it the case that only the first request went wrong and all of the requests afterwards succeeded?
+16Vincent Doppenberg wrote:
Hello Freddy,
If I would have to guess, I'd say that the request that resulted in the 502 status code was the first request to that application (sf/10288) and Indicium had to load the application model. This might have caused Indicium to go over the timeout that is configured on the reverse proxy, which I believe is nginx in your case.
Is it the case that only the first request went wrong and all of the requests afterwards succeeded?
When I for example do a refresh or activate a pre-flter.. I get a bunch of 400 errors.
If I refresh model.. it starts with the mentioned error again.
+16If I try to get the base view it says 200 OK but with failed..
so my tenant works.. but this view doesn't.. what can be the reason?
Hello Freddy,
The reason for the 400 Bad Requests is most likely the %2F in the hierarchy_id filter, which represents a forward slash character. If your reverse proxy decodes the %2F back to a forward slash when sending the request to Indicium, then you will get a 400 Bad Request. IIS does this as well, but we have added a rewrite rule to the web.config to resolve this issue.
Assuming that you are using nginx, this post might be helpful: https://serverfault.com/questions/459369/disabling-url-decoding-in-nginx-proxy
As for the 502 error, this is due to the timeout limit being too low on your reverse proxy. So both issues should be resolved through configuring your reverse proxy.
I hope this helps.
+16Vincent Doppenberg wrote:
Hello Freddy,
The reason for the 400 Bad Requests is most likely the %2F in the hierarchy_id filter, which represents a forward slash character. If your reverse proxy decodes the %2F back to a forward slash when sending the request to Indicium, then you will get a 400 Bad Request. IIS does this as well, but we have added a rewrite rule to the web.config to resolve this issue.
Assuming that you are using nginx, this post might be helpful: https://serverfault.com/questions/459369/disabling-url-decoding-in-nginx-proxy
As for the 502 error, this is due to the timeout limit being too low on your reverse proxy. So both issues should be resolved through configuring your reverse proxy.
I hope this helps.
Yeah, it at least led me to 3 more errors.. but finally it worked. 😁
However, what are the best-practices on time out values and proxy buffer sizes?
Hello Freddy,
The default request timeout on IIS is 110 seconds. We don’t really have a recommendation for this, because it depends on the application. But 110 seconds rarely leads to problems so that seems like a good value to suggest for now.
As for the proxy buffer sizes, I don’t have any suggestions for this without looking into it more. However, I would imagine that the default settings of nginx are good. This is not something that I would expect to need additional configuration.
+16Vincent Doppenberg wrote:
Hello Freddy,
The default request timeout on IIS is 110 seconds. We don’t really have a recommendation for this, because it depends on the application. But 110 seconds rarely leads to problems so that seems like a good value to suggest for now.
As for the proxy buffer sizes, I don’t have any suggestions for this without looking into it more. However, I would imagine that the default settings of nginx are good. This is not something that I would expect to need additional configuration.
I'm asking about the buffer sizes, because I get this error:;
upstream sent too big header while reading response header from upstream
which goes away after increasing the buffer sizes according to here: Nginx upstream sent too big header while reading response error - nixCraft (cyberciti.biz)
Hello Freddy,
The website that you linked seems to answer your question under the heading 'How do I find or set correct buffer size value?’.
1 person likes this
+16Hi
What is happening here: Files in the previewer aren't loading.
The last one says failed, but I don't get an error.
Hello Freddy,
A few questions:
- Are all of the file previews not working or just some?
- What happens if you fetch the preview URL in a separate tab?
- Do you see any errors in the console of the developer tools?
+16Vincent Doppenberg wrote:
Hello Freddy,
A few questions:
- Are all of the file previews not working or just some?
- What happens if you fetch the preview URL in a separate tab?
- Do you see any errors in the console of the developer tools?
I think I've resolved it, everything is showing now. Apparently the nginx defaults on Linux are quite low, so after increasing proxy read timeouts, I also had to increase the proxy buffer sizes. And there was an issue with Security-Enhanced Linux (SELinux), it was not permissive on the http user.
Thanks for the support and good questions, they have helped me getting everything installed.
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.