<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<font face="Helvetica, Arial, sans-serif">Yes, I have it there in some
configs but have found also that it's not as robust.<br>
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 &lt;no input
specified&gt;.<br>
Is that a bug or just some quirk of how ssl gets done?<br>
Chris :)<br>
</font><br>
mike wrote:
<blockquote
 cite="mid:bd9320b30809071215x794c3ea7ya303f22009bb69c1@mail.gmail.com"
 type="cite">
  <pre wrap="">You can set include fastcgi_params on the global http {} level ;)

On Sun, Sep 7, 2008 at 11:35 AM, Chris Savery <a class="moz-txt-link-rfc2396E" href="mailto:chrissavery@gmail.com">&lt;chrissavery@gmail.com&gt;</a> wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">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 <a class="moz-txt-link-freetext" href="http://theserverwiththedata.com">http://theserverwiththedata.com</a>;
            }
        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 :)

    </pre>
  </blockquote>
  <pre wrap=""><!---->

  </pre>
</blockquote>
</body>
</html>