The anatomy of a forward
Usually you can just ask Finch to forward a site by providing the
same URL you’d type to view it in your browser. There are, however,
some circumstances where you might need a little more control over the
details of each forwarded site. When you ask Finch to forward a URL
actually breaks that URL down into three parts:
- The host name of the local server (in this case: dev-site.local)
- The port to forward traffic to (in this case: 3000)
- The host header, most
commonly used with Virtual hosting (in
this case dev-site.local)
On the occasions where you
need fine-grained control over each part of the forward, you can use a slightly more complex
but more powerful syntax to tell Finch what to do.
Opting into the advanced syntax is as simple as prefixing your forwards
--advanced. In these cases, each part of the forward can be
explicitly specified as a colon-delimited list of the form server:port:hostHeader.
In time even more fine-grained control will be available via the advanced syntax, so
keep your eyes peeled!
If Finch isn’t directing requests at the correct local development server you might
have to give it a helping hand. The following example will forward all requests through to
the machine resolved by the host address dev-server.local on port 80, without a custom
host header (i.e. the domain Finch allocates you will be sent instead):
$ finch forward --advanced dev-server.local:80
dev-server.local only needs to be visible to your machine in order
for this to work.
If your web server relies on the host header to correctly route
inbound requests then Finch’s standard syntax will usually
provide the expected result, but on the rare occasions the target machine
and the host header need to be different, the following format provides
$ finch forward --advanced dev-server.local:80:mysite.dev
Note the subtlety here: we’re forwarding requests onto the host machine
resolved by the address dev-server.local but with a custom host header
Docs no good? Let us know!