How do I get a production website to load assets from local web server?
To redirect requests for assets on your local machine only
To get your local machine to use local files for certain JavaScript or CSS assets requested from a remote server, you could use an HTTP proxy/interception tool such as Charles. (Mac, Windows, and Linux. 30-day demo, then $50 to buy.)
To set up Charles to listen for remote requests and serve local files instead, follow these steps:
Download Charles.
Launch Charles and, when prompted, let it modify your proxy settings.
Visit the website you're testing in your browser. I'm using Chrome to visit Google in this example.
Find the website in Charles' 'structure' window in the left pane, then drill down through the folders to the requested asset you want to modify. I'm using Google's logo in this example.
Second-click the asset and choose 'map local' from the options:
Choose the file you want to load from your local filesystem instead of the remote asset:
Repeat for as many assets as you want to remap.
Force refresh your browser. You should find the assets are loaded from your local machine instead of the remote one.
To 'unmap' local files so that the remote ones are loaded again, follow these steps:
Choose Tools > Map Local from Charles' menu:
Click the rule[s] you wish to remove from the list, then click the 'remove' button:
There are free applications available which will let you do the same thing, such as WebScarab and Burp suite, but neither are as simple or beautiful to use as Charles, in my opinion.
The rest of this answer concerns the steps to take if you'd like a remote web server to load files from your computer for all users who visit the remote site. (Possible example use case: showing work to clients/colleagues when you can't reproduce the production site locally or stage a development server.)
To redirect requests for assets on all machines
To serve certain assets from your local machine for all machines accessing another remote web server, you can set up your local server to be accessible from the Web. A couple of options:
Localhost tunnelling services
These services help you share localhost over the web to make assets or entire sites available via a web address:
- Showoff.io
- Tunnlr
- Localtunnel
Showoff.io and Tunnlr are paid services at $5/month. Localtunnel is currently free.
Dynamic DNS
A free alternative is to use dynamic DNS hosting from a service such as afraid.org to point a web address at the webserver running on your local machine. Here's how it works:
Sign up at afraid.org.
Click the link in the email they send to activate your account and automatically log in.
Set up a new subdomain, which you'll use to access your localhost from the web. You can choose one of their free domains (such as 'mooo.com'); there's no need to register your own.
Download one of the many dynamic DNS applications for your operating system.
Run the application, which publishes your IP address to the afraid.org servers.
Set up a server to run on port 80 of your local machine, and allow traffic through port 80 on any firewalls you're running. How you do this depends on your operating system and hardware. (If you're using Mac OS X, for example, you need only turn on 'Web Sharing' in your System Preferences>Sharing pane.)
Visit the subdomain you created in step 3 in your web browser. (e.g. yourname.mooo.com). The name will be resolved to your machine's IP address and -- if you've configured your server and firewall correctly -- you should see the index file from your local machine.
You can then access assets in the public folder on your local machine over the web by using the full path to those assets with the afraid.org subdomain you created. For example: yourname.mooo.com/~yourMacUsername/images/hurrah.jpg
Naturally, you can reference that URL from another server to have it load files from your local machine.
[On the Mac, the public folder is the 'Sites' folder in your user directory. To access it, use your IP address or hostname followed by a tilde (~) and your Mac username. Other servers and operating systems work slightly differently.]
External Redirect
If you are OK with editing the production .htaccess
file then you could simply redirect requests for the necessary static assets to your local web server. The redirect would be conditional on the IP address accessing the site (ie. your external IP address).
For example, to redirect a specific asset to the same URL-path on the local server:
RewriteEngine On
RewriteCond %{REMOTE_ADDR} ^203\.0\.113\.111$
RewriteRule ^assets/main\.css$ http://local-web-server.com%{REQUEST_URI} [R,L]
All CSS files:
RewriteRule ^assets/.+\.css$ http://local-web-server.com%{REQUEST_URI} [R,L]
All assets:
RewriteRule ^assets/.+ http://local-web-server.com%{REQUEST_URI} [R,L]
You don't need to use a resolvable hostname (eg. local-web-server.com
), you could simply use the local IP address of your local web server directly (eg. 192.168.1.20
). However, by using a hostname, your local development server can use virtual hosts to serve multiple websites without having to change anything between projects.
The above are temporary (302) redirects. You could change these to permanent (301) by changing R
to R=301
. This will lessen the server requests as the browser will redirect from cache. However, you will need to clear the local browser cache when you are finished, in order to clear the cached redirect.
Disadvantages:
- You need access to and are willing to edit the production
.htaccess
file. - It's an external redirect. You'd never do this to serve live content, but it's perfectly OK for local testing.
Advantages:
- Your local development server does not need to be public.
- Works for all browsers on your development machine.
- If the DNS is public for
local-web-server.com
(which points to the local IP address of your web server) then anyone (or any device) on your local network can also see these local assets.
Separate hostname for static assets
If the production site uses a separate hostname for all static assets, eg. static.example.com
then you can simply override this in your local DNS (HOSTS file) to point to your local development server instead.
Disadvantages:
- Unless you have a centralised DNS server for your local network then other devices on your local network will not be able to see the local assets unless they modify their own HOSTS file (which is not always possible on mobile devices).
Advantages:
- No server-side changes required on the production server.
Reverse Proxy
To make this seamless (ie. no redirect) then you could configure a reverse proxy on the production server. You would still have similar directives in .htaccess
to proxy the necessary assets.
Disadvantages:
- Need access to the production server in order to configure a reverse proxy.
- Need access to the production server in order to proxy the requests (possibly in
.htaccess
). - Your local development server would need to be "public".
Advantages:
- You could enable remote users to see the full "development" site.
Livereload that watches my local files and refreshes the live site on change.
That's really a separate issue. Many code editors these days have "live preview" features/plugins that enable this feature.