# Several hard Apache ProxyPass rules needed under path + User Avatar Picture upload problem
**URL:** https://meta.discourse.org/t/several-hard-apache-proxypass-rules-needed-under-path-user-avatar-picture-upload-problem/126722
**Category:** Self-hosting
**Created:** [24 באוגוסט, 2019, 8:30am UTC](https://meta.discourse.org/t/several-hard-apache-proxypass-rules-needed-under-path-user-avatar-picture-upload-problem/126722 "2019-08-24T08:30:23Z")
**Posts on this page:** 5
**Page:** 1
### Author:  [@Marco\_Vasapollo](https://meta.discourse.org/u/Marco_Vasapollo)
#### Post date: [24 באוגוסט, 2019, 8:30am UTC](https://meta.discourse.org/t/several-hard-apache-proxypass-rules-needed-under-path-user-avatar-picture-upload-problem/126722/1 "2019-08-24T08:30:23Z")
Hello.
We have a v2.4.0.beta2 +346 Discourse installation that was **originally** available at `include.metaring.com`,
using Apache HTTP Server on Ubuntu that:
- Redirects all HTTP requests to HTTPS
- Manages by itself the SSL certificate (LetsEncrypt)
- All requests were redirected by Proxy to using **nginx http sock** , so Discourse Docker ports 80 and 443 are disabled/unused
We did
`./launcher enter app`
`rails c`
`[1] pry(main)> SiteSetting.force_https = true`
`=> true`
To be extremely sure that everything was served in HTTPS (we had several errors if not)
And everything was working fine.
Then we decided to move the application (without touching DB or other stuff) under `include.metaring.com/` **discourse** , so we edited the _app.yml_ file like this:
- `DISCOURSE_HOSTNAME: include.metaring.com` \<— Untouched, same as before
- `DISCOURSE_RELATIVE_URL_ROOT: /discourse`
Then, to be _extremely_ sure, we did:
`./launcher stop app`
`./launcher destroy app`
`./launcher cleanup`
`./launcher rebuild app`
Of course we also inserted in Apache config file the rules to correctly ProxyPass from _/discourse_ to _unix:/../../nginx.http.sock|[http://localhost/\*discourse](http://localhost/*discourse)_\*
After this, the application was of course online, but had a lot of problems:
1. All static content stuff (plugins, assets, images, javascripts, uploads) weren’t available. After long debug sessions and non-fruitful web searches for letting them work we created some proxy rules in Apache to tunnel them to the **root** _localhost_ path, **without** the _/discourse_ prefix (eg. _/disourse/plugins_ points to → _unix:/../../nginx.http.sock|http:// **localhost/plugins** _ and so on)
2. Some _/uploads_ paths came from web pages **without** the _/discourse_ prefix, so we needed to write another Apache proxy rule that moves from _/uploads/_ to _unix:/../../nginx.http.sock|[http://localhost/discourse/uploads](http://localhost/discourse/uploads)_
3. Now the most strange thing: when the client sends requests containing _/uploads/default/_ or _/discourse/uploads/default/_ (static content) we need to follow the solution at point 1 described before and redirect them both to `http://localhost/uploads/default/` ( **without** the _/discourse_ prefix), while other _/uploads/_ or _/discourse/uploads/_ requests that don’t contain _/default_ prefix in path must be redirected to `http://localhost/discourse/uploads/` (noticed that without the _default_ path means that they are webservices calls)
With all these 9 proxy rules we inserted everything works fine again even under the _/discourse_ path. But we found extremely strange that we needed to write all this stuff to let everything work again.
Are we doing something wrong?
Is there any other smart method to manage this situation?
**=== EDIT ===**
Forgot another thing that is maybe linked:
When the user tries to upload a custom picture to use as personal avatar, the upload goes OK and the miniature of the picture is correctly shown.
But when the _Save changes_ button is pressed and the page is reloaded, the avatar comes back to the default user avatar
Checking the `produciton.log` file, it shows that the error is `Code 418`.
Other picture uploads work well.
Thanks in advance for responses and for your amazing work!
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [24 באוגוסט, 2019, 11:23am UTC](https://meta.discourse.org/t/several-hard-apache-proxypass-rules-needed-under-path-user-avatar-picture-upload-problem/126722/2 "2019-08-24T11:23:53Z")
Subfolder installs are much more complex and not recommended.
---
### Author:  [@Marco\_Vasapollo](https://meta.discourse.org/u/Marco_Vasapollo)
#### Post date: [24 באוגוסט, 2019, 11:29am UTC](https://meta.discourse.org/t/several-hard-apache-proxypass-rules-needed-under-path-user-avatar-picture-upload-problem/126722/3 "2019-08-24T11:29:18Z")
Understood. Thanks
But we have no chances in this case so if no any other suggestion we will keep monitored the situation to see if there are other Proxy rules to manage.
Don’t you have any suggestion about the stuff of user upload? Looks kind of db storage problem, isn’t it?
---
### Author:  [@system](https://meta.discourse.org/u/system)
#### Post date: [11 במרץ, 2023, 11:20am UTC](https://meta.discourse.org/t/several-hard-apache-proxypass-rules-needed-under-path-user-avatar-picture-upload-problem/126722/4 "2023-03-11T11:20:35Z")
---
### Author:  [@Stephen](https://meta.discourse.org/u/Stephen)
#### Post date: [11 במרץ, 2023, 12:27pm UTC](https://meta.discourse.org/t/several-hard-apache-proxypass-rules-needed-under-path-user-avatar-picture-upload-problem/126722/5 "2023-03-11T12:27:47Z")