Ensuring Origin Deliverability

When imgix receives a request for an asset that is not cached, we’ll first try to retrieve the asset from your Source’s Origin. Because of this, it’s important to ensure that imgix has unrestricted and unobstructed access to your origin files.

Asset Availability

The asset should be available as soon as it has been completely uploaded to the Origin. If imgix sees that the asset is not available, it will return a 404 and cache the response. By default, the error cache TTL is 5 minutes. imgix will cache error responses according to the error cache TTL set in your Source settings.

Once the asset has been served, it can take up to an hour for numbers to update in your Dashboard Analytics. Analytics for any error codes will show up once the asset causing the error code has been served successfully.

Identifying requests from imgix

Requests from imgix will use a dynamic set of IP addresses that change over time. Additionally, requests from imgix will always include a version of imgix/ (ex: imgix/3.0).

This information can be used in a few different ways, such as putting imgix on an allowlist or setting up different security rules for requests coming from imgix.

Allowlisting imgix

Some customers prefer that their origin servers are not publicly accessible. In the case of S3, Azure, and GCS Sources, imgix is able to successfully retrieve assets from those protected buckets by using valid credentials entered on the Source configuration page. However, in the case of Web Folder and Web Proxy Sources, such security settings can prevent imgix from being able to retrieve assets. If the service is unable to retrieve an asset from the Origin, then we will return a 403 error.

The best method of making sure imgix can pull assets from your Origin is by allowlisting our user-agent. Since our user-agent is not expected to change anytime in the future, this is the recommended method of allowlisting for future compatibility.

If you are using a Web Folder or Web Proxy, you can define additional security headers to authenticate requests. See the next section for more info.

Authenticating Requests to Web Folder and Web Proxy Origins

[Web Folder] and Web Proxy Sources can be configured to send additional authorization headers in the request to Origins. Here is an example request sent to a Web Folder Origin with Authentication enabled:

{
  "headers": {
  ....
  "Authorization": "Basic {base_64_encoded_username_password}",
  "X-Imgix-Signature": {your_signature},
  "X-Imgix-Signature-Host": {origin_host},
  "X-Imgix-Signature-Request-Id": {request_id},
  "X-Imgix-Signature-Timestamp": {timestamp}
  }
}

Visit the documentation for more information on configuring authorization headers for Web Folder or Web Proxy Sources:

• Web Folder Authorization
• Web Proxy Authorization

Disable Rate Limits

It’s common to have some security measures against a large number of synchronous requests to different URLs on your Origin. This often manifests as an error being returned from your Origin once the number of requests has reached a threshold from the same IP address.

With imgix, there is a low chance of this issue occurring since requests will often hit our cache more often than they will hit your Origin. However, in cases where a large number of URLs are added or when a new Source is exposed to a large amount of traffic, it’s not uncommon for your Origin to impose a rate limit against imgix.

Such issues are often temporary. Regardless, if you have any rate limits in place, you may want to look into exempting imgix from those limits.

Foreign Characters and Character Encoding

When file names use foreign characters, imgix will encode the file name and attempt to retrieve it at the encoded path. As a result, if that encoded path returns a 404​, imgix will also return the asset as a 404. Ideally, the Origin should automatically route the request to the encoded file path.

Additionally, assets that are served using encoded characters instead of the original characters can result in issues with purging. For example, assets that are served with /%2f instead of / will be recognized as two different asset URLs due to RFC spec 3.2.3 concerning URI comparisons. As a result, purging the asset that uses encoded characters may not purge their non-encoded variants depending on whether or not URL unsafe characters are used.

AWS S3 supported regions

Amazon’s Storage Service (S3) allows for storing data in a specific geographical region. An imgix AWS S3 Source can connect to a bucket in one of the supported regions listed in the table below.

Known Issues for Specific Origins

There are some known compatibility issues when fetching from certain Web Folder or Web Proxy Origins, which we have documented below.

Imperva

Imperva is a well-known security platform that is commonly used to protect access to online assets.

One of their security features is to block and prevent access to assets by bots. This is done by sending a “garbage” cookie header value which prevents the bot from completing a request.

Unfortunately, this security feature also blocks the imgix rendering service from accessing files from an Imperva-fronted Origin. Unless it is properly configured, requests to an imgix Source using an Imperva Origin can return a 503 error.

To prevent this issue, we recommend either:

• Bypassing Imperva by connecting your imgix Source directly to the Origin
• Allowlisting imgix so the imgix rendering service can access assets through Imperva
• Contacting Imperva support to turn off the security feature that blocks bot access

IPFS

IPFS stands for Interplanetary File System and is a decentralized file system that relies on a peer-to-peer hypermedia protocol.

Due to the nature of IPFS, timeout errors can be observed for a small number of Origin fetches to an IPFS Origin, depending on which peer is returning the file. These errors are related to the timing response and availability of a file as we fetch the file from the Origin, and are expected to succeed on subsequent retries as long as the file is available.

Once a file is fetched, it will be cached in the imgix rendering service for some time, reducing the chances of timeout errors and the number of calls to the IPFS Origin.

You can reduce the number of requests to IPFS Origins and therefore increase your deliverability success rate by optimizing your caching settings in your imgix Source. The suggested value for cache TTL is one year.