How To Fix: 404 Error When Requesting Images Hosted on IIS Under a Frontend Website

Hosting images on an IIS server seems to be pretty much a basic task. 

I mean all you need is to create a virtual directory or even a website and just move the pictures to the physical path of this website and then you can access it through:

server-hostname.com/virtual-directory/picture-name.jpg

Well while this might be something that you can apply easily, following the same steps but instead of creating a new website you go for adding a virtual directory under an existing frontend website might yield the world famous 404 error.

The Problem

I was working on a project once where I needed to create an API that takes an image url as a parameter and downloads it on the same server where the UI of the application was hosted. 

I will show you how to create such an API in an upcoming post but right now let's focus on creating a virtual path under your frontend website.


After you open your IIS manager right click your frontend website click on Add Virtual Directory and select the physical path (eg. C:/example/server-images) where you want to store your images and then provide a virtual path (eg. images) that maps to this image directory.

Add any image to the physical directory and you should be able to access it through the url format I mentioned at the beginning of the article but you might face a 404 error. So now what?

The Cause

It turns out that the web.config of the frontend website had a rewrite rule.

    <rewrite>

      <rules>

        <rule name="myapp">

          <match url="/*" />

          <action type="Rewrite" url="server.js" />

        </rule>

      </rules>

    </rewrite>

This means that any incoming request will be redirected to server.js because of the wildcard matching (/*) including my call to my virtual path (/images). Then how do we fix this?

The Solution

Simply add a condition that exempts your virtual path from the url rewrite rule in order to allow you requests to reach your virtual path such as follows but just make sure to replace (/images/) with the name of your virtual path.

<rewrite>

  <rules>

    <rule name="myapp">

      <match url="/*" />

      <conditions>

        <add input="{REQUEST_URI}" pattern="^/images/" negate="true" />

      </conditions>

      <action type="Rewrite" url="server.js" />

    </rule>

  </rules>

</rewrite>

By doing so you will finally be able to reach your images on your virtual path.


Perfect! Now your problem should be solved. See you in later posts!

Comments

Post a Comment

Popular posts

Why I Hate Microservices Part 1: The Russian Dolls Problem 🪆🪆🪆

Image
     People always want the newest things. The more trendy something is, the more it appeals to most people. Same applies to technology. Adding the word microservices to the CV can help it shine a little bit. These are some of the thoughts I was having while I was 2 hours deep into debugging an issue in a project that involved .Net, Kafka, SignalR, React js, Elasticsearch, ECS, MediatR and more. Beware of Microservices  ⚠️ What I'm about to share is a cautionary tale for people who are on the verge of shifting their solution into a microservices architecture. Before you start implementing such an architecture, please read carefully the decisions that others have made along with their consequences so that you can see for yourself the outcome of each design decision instead of falling for the same mistakes. Before anything : The case study that I’m about to discuss might have had its problems. However, the people who made the design decisions are very good software e...
Read more

Why I Hate Microservices Part 3: The Identity Crisis 😵

Image
       Imagine going out to buy bread. And you know that there are two types of bakeries. One that gives you the bread right away because they know exactly when it's going to be done. The other kind takes the order from you and tells you to go home and it will deliver the bread to you once it's ready because it's unclear for them when it's going to be done. Then it's clear for you what to expect when dealing with both sorts of bakeries. Now, imagine if there were a third type of bakeries. One that tells you that it's going to give it to you right away while it's actually unclear for them when the bread is going to done. So, you expect the bakery to behave in a certain way but it will actually behave in another. Well, imagine working in such a bakery. Eventual 📨 VS Transactional⚡ In my humble opinion, the problem that I'm discussing in this article is probably the most critical one when designing a system. It's a problem about the identity of your so...
Read more

Why I Hate Microservices Part 2: The Who's Telling the Truth Problem 🤷

Image
      When designing a system, you should not limit yourself with using only one type of databases. Some business needs might require having a more flexible sort of databases like NoSQL / Document databases.  One of these databases is Elasticsearch ,   which is a topic that I have talked about in a previous post that you should definitely check out. However, if you use more than one database for your system, making sure that all your databases are in sync is crucial . How It Started 🚩 As I said in my previous post . The other sort of problems that we have faced while working on the microservices project is data inconsistency. To explain this problem I have to tell you why the system needed an Elasticsearch index. In microservices projects you usually have more than one database, one for each service/domain. The client-side needed an aggregated document of the data from all the databases. Which in microservices is called The Aggregate Root ,   and that is ...
Read more