Equivalent to .htaccess rewrite on localhost

My images are served from a different domain.

This .htaccess works on my live server:

RewriteEngine on
RewriteCond %{REQUEST_URI} ^(/images)$
RewriteRule ^(.*)$  http://b.robnugen.com/ [R=302,L]
RewriteCond %{REQUEST_URI} ^(/images)/(.*)$
RewriteRule ^(.*)$  http://b.robnugen.com/%2 [R=302,L]

This allows me to display images using

[image alt text](/images/path/to/image.png)

But the images appear broken when I test locally.

I guess one solution is to keep a local copy of the images, but I hope Hugo can do this:


Can this


be rewritten locally as


Hugo doesn’t do any rewriting of URLs. It’s beyond the scope of what Hugo server is designed to do. If you want this functionality use something like Nginx or Caddy in front of Hugo.

1 Like

TL;DR: Stop doing that.

First, Hugo doesn’t support that. My suggestion would be to move your images into the static/images/ folder of your Hugo project, remove the mod_rewrite junk from apache, and be done with it. You may want to reverse the rewrite logic for a spell so that all the search engines can update to the new location, and then remove the rewrite rules.

Second, I’m really curious why in the world you would want to do such a thing in the first place. You’re basically forcing two HTTP requests for every image on your site, which wastes bandwidth and creates latency.

1 Like

Maybe create a config variable to contain either ‘/images/’ or ‘http://b.robnugen.com/’, and change it as necessary depending on whether you’re working locally or deploying?

1 Like

@thunderrabbit A little curious as to why you’re doing this, but here are a few ideas:

  1. Prepend the full URL on the client in Javascript. This is easy but super bad form, and I would not recommend it since it doesn’t help your page speed and it’s unnecessarily hackish.
  2. Use your text editor to find/replace with a reg ex to prepend the full URL to the (what I assume are ) markdown files.
  3. Write a bash/ruby/go/node script that goes through your .md locally before publishing.
  4. Create a global variable that contains whatever chunk of the URL you want to reuse, but this might not make it easier for you to write shorter URLs in markdown.
  5. This is totally unsolicited, but I’d recommend having the URLs rewritten to //b.robnugen.com/images/myfancyimage.png, and drop the http when writing URLs in your markdown files. Might not apply to your current query, but it might have some benefit w/r/t other assets in a future world of SSL and mixed content errors.
1 Like

The images are on the other server partially for historical reasons, but mostly because there are a lot of images and I want the image server to be their primary source (in terms of source control), not my local computer, which has a higher failure rate.

I would just put them on Github in their own repo, then clone that into my local Hugo project, but then I have to store a lot of images on my local computer (twice!) and Github (or other provider) does as well.

So my thinking was: put the images on their own server (which does thumbnailing and caching), but do not update my old journal entries which link to /images for each image.

I guess I could update all the links in all my journal entries to specify http://b.robnugen.com instead of /images + HTTP redirect, but that makes a pain in the future if I ever change my image server URI.

@rdwatters, your option 2 would actually solve it even though I didn’t want to do it that way originally.

Once I correctly update all instances of /images to //b.robnugen.com there will be far fewer false positives if I ever have to move the server.

Thank you guys for your suggestions; I may start to have fewer redirects in the future!