So what exactly is reverse proxy in.
Simply put a reverse proxy act as an intermediary between a client for example a browser and the resource
itself.
For example the most common use case on in generics is one we've already covered BHB when we implement
a be back in using P P F be M engine X. acted as a reverse proxy between the client and BHB fbm.
So in other words interpreting the client's request fetching that request from patch P If p.m. and then
sending it back to the client.
Hence the term reverse with the client assuming all requests are coming to and from that engine X server.
This is of course a very powerful feature for many applications.
But in the context of any generics as a web server it will most often be used to proxy somewhere the
back in service be that patch be no Dodger s Ruby etc..
I still have that engine Xserve from the previous list and running.
Hello from in Genex.
So to demonstrate the most basic reverse proxy I'll start a new web server using P HP.
Again with that response style which echoes Hello from page B test that's working all 9 9 9 9 which
it is now.
Let's say we want to access this BHB server via our engineered server.
This one on port 8 8 8 8 and we want to do so by accessing the slash P HP path or request you are right.
I'll switch back to the engine XT configuration file we are using create that new location block for
Slash patch P and now two proxy requests on this path to the PDB server.
We can say proxy underscore pass which should look familiar from the Patch be back end Listen HTC be
local post 9 9 9 9 the full You are all of that BHB server with a trailing slash which is important
and will cover in a minute.
I'll just wrap this in quotes to make it a bit more readable.
Reload engine X server with the S flag and reload and now test this reverse proxy by requesting that
slash patch.
Request on our engine X server.
Hello from BHB server.
So a response clearly from I appear to be server but accessed and reverse proxied via a were engine
X server kurla again with out the slash BHP.
And again we're back to getting the engine X response as before.
There is of course no restrictions to this proxy server or servers being on the same system either.
For example I'll create a third location block.
Listening for engine X org.
And proxy this one to engine X dot org.
So a remote site.
Reload the configuration.
Try that.
Engine X or path.
And we get a whole bunch of HDMI L..
I'll access it via the browser.
Where at load.
As if we're visiting engine X dot org directly so a completely remote website being proxied via our
server.
Now when I mentioned the importance of keeping the trailing slash on the proxy drl the reason for this
is because of how engine X handles proxy paths to demonstrate.
I'll create a new page prescript to pass to appear to be server corlett show underscore request dot
patch B.
Open that new file and in.
I'm simply going to echo out the request you are right as received on the pier to be server.
So in other words what our engineers proxy is requesting.
Server.
Request.
You are I.
Save that and launched a BHB server with a new file.
Show underscore request.
OK.
Now when we call this engine X server the HP server receives slash or root.
So there's no request being passed to the pier every server.
If however I changed the proxy path in the engine X configuration file to not include the trailing slash
like so.
Curl again.
We get slash P B so the entire you are right.
As we requested it from the engine X proxy server.
What this means then is that unless we specify a proxy path engine X assumes the original request path.
Now sure you can create use cases for this but ultimately it's inconsistent and not recommended.
So at that request you arrive to the proxy Dural.
In this case when having the U R L specified as before we can still pass a customer request after the
proxy path say BHB slash some slash you are L..
What the B.
B server receives is that last part some u are l.
Don't worry too much about the double slashes at the start here.
It's just how engineers handles the u r l substitution but it's normalized automatically and shouldn't
cause any issues.
This then being a logical approach to passing request you rise to a proxy server.
Another important aspect of using engine X as a reverse proxy is passing custom headers to either the
proxy server I appear to be server in this case or to the client on the reverse part of the proxy.
First we can pass headers to the client using the standard add header directive.
I'll name this header proxied with a value of engine x.
Reload our configuration and test by curling that patch piece path.
And we see the header.
Remember however this is being added to the client.
Only on the reverse part of the proxy so to add a header that gets sent to the proxy server.
O appear each piece server we have to change this slightly.
First let's modify that show request file to print out all request headers var dump get all headers.
If you're not familiar with Patch B var dump is just a very verbose way of logging out variable or the
return value of this function in our case.
Restart the peer to p server.
Test that.
We get all our headers but of course not that proxy to header We added as that's going to the client
to add this to the proxy request then we can simply change add header to proxy set header meaning set
this header on the proxy request reload.
Call that again and this time the very first value of this dumped headers array is that proxy to header
with the value in Genex.
That wraps up using engine X as a reverse proxy which as you can see engine X makes very easy in the
next list will apply what we've learnt here to create a basic load balancer.