WEBVTT 00:06.170 --> 00:09.010 So what exactly is reverse proxy in. 00:09.020 --> 00:15.800 Simply put a reverse proxy act as an intermediary between a client for example a browser and the resource 00:15.800 --> 00:17.120 itself. 00:17.120 --> 00:23.480 For example the most common use case on in generics is one we've already covered BHB when we implement 00:23.480 --> 00:32.240 a be back in using P P F be M engine X. acted as a reverse proxy between the client and BHB fbm. 00:32.270 --> 00:38.810 So in other words interpreting the client's request fetching that request from patch P If p.m. and then 00:38.810 --> 00:40.640 sending it back to the client. 00:40.670 --> 00:47.510 Hence the term reverse with the client assuming all requests are coming to and from that engine X server. 00:47.510 --> 00:50.800 This is of course a very powerful feature for many applications. 00:50.990 --> 00:56.740 But in the context of any generics as a web server it will most often be used to proxy somewhere the 00:56.780 --> 01:02.360 back in service be that patch be no Dodger s Ruby etc.. 01:02.810 --> 01:06.250 I still have that engine Xserve from the previous list and running. 01:07.720 --> 01:09.580 Hello from in Genex. 01:09.610 --> 01:15.940 So to demonstrate the most basic reverse proxy I'll start a new web server using P HP. 01:15.970 --> 01:24.280 Again with that response style which echoes Hello from page B test that's working all 9 9 9 9 which 01:24.280 --> 01:25.470 it is now. 01:25.480 --> 01:29.740 Let's say we want to access this BHB server via our engineered server. 01:29.980 --> 01:38.040 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. 01:38.290 --> 01:43.570 I'll switch back to the engine XT configuration file we are using create that new location block for 01:43.570 --> 01:50.150 Slash patch P and now two proxy requests on this path to the PDB server. 01:50.170 --> 01:58.030 We can say proxy underscore pass which should look familiar from the Patch be back end Listen HTC be 01:58.120 --> 02:06.280 local post 9 9 9 9 the full You are all of that BHB server with a trailing slash which is important 02:06.400 --> 02:07.990 and will cover in a minute. 02:08.410 --> 02:11.950 I'll just wrap this in quotes to make it a bit more readable. 02:13.070 --> 02:20.330 Reload engine X server with the S flag and reload and now test this reverse proxy by requesting that 02:20.330 --> 02:21.250 slash patch. 02:21.340 --> 02:23.500 Request on our engine X server. 02:24.500 --> 02:26.470 Hello from BHB server. 02:26.780 --> 02:33.120 So a response clearly from I appear to be server but accessed and reverse proxied via a were engine 02:33.120 --> 02:37.350 X server kurla again with out the slash BHP. 02:37.550 --> 02:40.990 And again we're back to getting the engine X response as before. 02:41.730 --> 02:47.720 There is of course no restrictions to this proxy server or servers being on the same system either. 02:47.730 --> 02:50.610 For example I'll create a third location block. 02:51.490 --> 02:53.680 Listening for engine X org. 02:55.230 --> 02:58.130 And proxy this one to engine X dot org. 02:58.210 --> 02:59.710 So a remote site. 03:01.090 --> 03:03.070 Reload the configuration. 03:04.130 --> 03:04.710 Try that. 03:04.730 --> 03:06.430 Engine X or path. 03:08.960 --> 03:11.690 And we get a whole bunch of HDMI L.. 03:11.880 --> 03:14.190 I'll access it via the browser. 03:17.630 --> 03:18.550 Where at load. 03:18.590 --> 03:25.400 As if we're visiting engine X dot org directly so a completely remote website being proxied via our 03:25.400 --> 03:26.140 server. 03:26.870 --> 03:32.750 Now when I mentioned the importance of keeping the trailing slash on the proxy drl the reason for this 03:32.750 --> 03:36.910 is because of how engine X handles proxy paths to demonstrate. 03:36.920 --> 03:44.080 I'll create a new page prescript to pass to appear to be server corlett show underscore request dot 03:44.130 --> 03:45.220 patch B. 03:46.010 --> 03:48.720 Open that new file and in. 03:48.740 --> 03:54.290 I'm simply going to echo out the request you are right as received on the pier to be server. 03:54.380 --> 03:57.960 So in other words what our engineers proxy is requesting. 04:00.320 --> 04:01.730 Server. 04:02.520 --> 04:03.190 Request. 04:03.210 --> 04:04.140 You are I. 04:06.460 --> 04:10.310 Save that and launched a BHB server with a new file. 04:11.270 --> 04:13.190 Show underscore request. 04:15.310 --> 04:15.500 OK. 04:15.520 --> 04:21.320 Now when we call this engine X server the HP server receives slash or root. 04:21.790 --> 04:25.560 So there's no request being passed to the pier every server. 04:25.570 --> 04:32.050 If however I changed the proxy path in the engine X configuration file to not include the trailing slash 04:32.200 --> 04:33.240 like so. 04:34.930 --> 04:36.580 Curl again. 04:37.360 --> 04:41.110 We get slash P B so the entire you are right. 04:41.140 --> 04:44.070 As we requested it from the engine X proxy server. 04:44.140 --> 04:50.960 What this means then is that unless we specify a proxy path engine X assumes the original request path. 04:51.130 --> 04:57.290 Now sure you can create use cases for this but ultimately it's inconsistent and not recommended. 04:57.370 --> 05:00.980 So at that request you arrive to the proxy Dural. 05:01.090 --> 05:07.720 In this case when having the U R L specified as before we can still pass a customer request after the 05:07.720 --> 05:13.290 proxy path say BHB slash some slash you are L.. 05:14.760 --> 05:15.350 What the B. 05:15.370 --> 05:20.030 B server receives is that last part some u are l. 05:20.140 --> 05:23.780 Don't worry too much about the double slashes at the start here. 05:23.920 --> 05:29.980 It's just how engineers handles the u r l substitution but it's normalized automatically and shouldn't 05:29.980 --> 05:31.450 cause any issues. 05:31.510 --> 05:37.140 This then being a logical approach to passing request you rise to a proxy server. 05:37.210 --> 05:43.150 Another important aspect of using engine X as a reverse proxy is passing custom headers to either the 05:43.150 --> 05:50.140 proxy server I appear to be server in this case or to the client on the reverse part of the proxy. 05:50.220 --> 05:55.090 First we can pass headers to the client using the standard add header directive. 05:55.450 --> 06:00.280 I'll name this header proxied with a value of engine x. 06:00.940 --> 06:05.980 Reload our configuration and test by curling that patch piece path. 06:08.530 --> 06:10.190 And we see the header. 06:10.330 --> 06:13.270 Remember however this is being added to the client. 06:13.300 --> 06:18.760 Only on the reverse part of the proxy so to add a header that gets sent to the proxy server. 06:18.780 --> 06:22.740 O appear each piece server we have to change this slightly. 06:22.760 --> 06:31.530 First let's modify that show request file to print out all request headers var dump get all headers. 06:31.750 --> 06:38.380 If you're not familiar with Patch B var dump is just a very verbose way of logging out variable or the 06:38.380 --> 06:41.100 return value of this function in our case. 06:41.140 --> 06:43.110 Restart the peer to p server. 06:43.930 --> 06:44.970 Test that. 06:45.720 --> 06:51.180 We get all our headers but of course not that proxy to header We added as that's going to the client 06:51.810 --> 06:59.850 to add this to the proxy request then we can simply change add header to proxy set header meaning set 06:59.880 --> 07:03.530 this header on the proxy request reload. 07:04.710 --> 07:11.220 Call that again and this time the very first value of this dumped headers array is that proxy to header 07:11.490 --> 07:13.730 with the value in Genex. 07:13.890 --> 07:19.950 That wraps up using engine X as a reverse proxy which as you can see engine X makes very easy in the 07:19.950 --> 07:24.290 next list will apply what we've learnt here to create a basic load balancer.