Proxy for POST update requests

[Chris Savery]

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 :)
>>
>>     
>
>
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nginx.org/pipermail/nginx/attachments/20080908/7a5b63fd/attachment.html>