# Proxy for POST update requests

**URL:** <https://www.ruby-forum.com/t/proxy-for-post-update-requests/147969>\
**Category:** NGINX\
**Created:** [September 7, 2008, 8:42pm UTC](https://www.ruby-forum.com/t/proxy-for-post-update-requests/147969 "2008-09-07T20:42:59Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![yetanothergeek](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/y/8e8cbc/32.png) [@yetanothergeek](https://www.ruby-forum.com/u/yetanothergeek)\
**Post date:** [September 7, 2008, 8:42pm UTC](https://www.ruby-forum.com/t/proxy-for-post-update-requests/147969/1 "2008-09-07T20:42:59Z")

</div>

Well, I got this working and it’s pretty nice too. I just wanted to post  
a couple notes here in the hope they may help someone else who needs to  
do this.  
relevant config looks like this,

location ~ .php$ {  
proxy\_set\_header WhatSlave $host;  
if ($request\_method = ‘POST’) {  
proxy\_pass [http://theserverwiththedata.com](http://theserverwiththedata.com);  
}  
fastcgi\_pass 127.0.0.1:9000; include fastcgi\_params;  
}

Notice I added a set header line. This was because in some cases the  
master server needs to know where the request was proxied from. In some  
cases it needs to do a redirect, eg. secure login. And that set header  
line causes a header to appear in the $_SERVER variable with the HTTP_  
prefix. eg. HTTP\_WHATSLAVE and has value of the host without http  
prefix.

Of course, the master server is running mysql replication and the data  
saved during the POST comes back to the slave server pretty quickly. In  
this setup all the GET requests drop through to the fastcgi locally and  
access the data on the slave. The POST requests pas up to modify data on  
the master. Good idea: give the local mysql user only “select”  
privileges to make sure it doesn’t nasty up the local data. If you allow  
altering data locally when doing replication you will create big  
headaches sooner or later.

Chris 🙂

---

<div class="post-metadata">

**Author:** ![yetanothergeek](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/y/8e8cbc/32.png) [@yetanothergeek](https://www.ruby-forum.com/u/yetanothergeek)\
**Post date:** [September 7, 2008, 9:24pm UTC](https://www.ruby-forum.com/t/proxy-for-post-update-requests/147969/2 "2008-09-07T21:24:03Z")

</div>

You can set include fastcgi\_params on the global http {} level 😉

---

<div class="post-metadata">

**Author:** ![yetanothergeek](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/y/8e8cbc/32.png) [@yetanothergeek](https://www.ruby-forum.com/u/yetanothergeek)\
**Post date:** [September 8, 2008, 1:01am UTC](https://www.ruby-forum.com/t/proxy-for-post-update-requests/147969/3 "2008-09-08T01:01:45Z")

</div>

Yes, I have it there in some configs but have found also that it’s not  
as robust.  
In my testing I have found that if it is placed in http section then for  
some reason on https servers it doesn’t get included. Is there supposed  
to be a separate section for https? I should look into that. Anyway, I  
have found I need to include it at the server level for those listening  
on 443 and using ssl otherwise they result in .  
Is that a bug or just some quirk of how ssl gets done?  
Chris 🙂

---

<div class="post-metadata">

**Author:** ![yetanothergeek](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/y/8e8cbc/32.png) [@yetanothergeek](https://www.ruby-forum.com/u/yetanothergeek)\
**Post date:** [September 8, 2008, 1:17am UTC](https://www.ruby-forum.com/t/proxy-for-post-update-requests/147969/4 "2008-09-08T01:17:34Z")

</div>

as far as i know it should make no difference. http and https can be  
inside the same http {} block…
