Proxy for POST update requests

[mike]

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


On Sun, Sep 7, 2008 at 3:55 PM, Chris Savery <chrissavery at gmail.com> wrote:
> 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 <no input specified>.
> Is that a bug or just some quirk of how ssl gets done?
> Chris :)
>
> mike wrote:
>
> You can set include fastcgi_params on the global http {} level ;)
>
> On Sun, Sep 7, 2008 at 11:35 AM, Chris Savery <chrissavery at gmail.com> wrote:
>
>
> 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;
>             }
>         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 :)
>
>
>
>