"X-Resolve-Urls" Header has changed

Support
#1

I have…

I’m submitting a…

  • [X] Regression (a behavior that stopped working in a new release)
  • [ ] Bug report
  • [ ] Performance issue
  • [X] Documentation issue or request

Current behavior

Expected behavior

Minimal reproduction of the problem

Environment

App Name:

  • [ ] Self hosted with docker
  • [ ] Self hosted with IIS
  • [ ] Self hosted with other version
  • [X] Cloud version

Version: [VERSION]

Browser:

  • [ ] Chrome (desktop)
  • [ ] Chrome (Android)
  • [ ] Chrome (iOS)
  • [ ] Firefox
  • [ ] Safari (desktop)
  • [ ] Safari (iOS)
  • [ ] IE
  • [ ] Edge

Others:

Yesterday we discovered that all the images on our production websites were broken due to a change in the request headers that resolve Assets

We had been using “X-Resolve-Urls” and from what I found, about 3 weeks ago there was a change to “X-ResolveUrls”.

If anyone is having issues with their assets you will need to check your headers and adjust your code accordingly.

1 Like
#2

Thanks a lot. I am very sorry. I was in the mode to make things more consistent and did not pay attention on that. In general this is something I would like to remove in the not so far future.

#3

Thanks,

When you are going to remove it, please provide some warning. We will have rework a lot of our code if this header gets removed.

#4

Sure. What is the main benefit from your side? It does not provide extra information that are not available anyway…

#5

We use it with the REST API queries. Without this header it simply returns the ID of the asset.

We use the X-ResolveUrls so we don’t have to compile the full source URL and/or send another request to pull the asset data from the ID.

For GraphQL we normally just define the data structure we want, but we still use the traditional API throughout our codebase.

#6

But the result is just the asset ID (which is known) and the app name (which is usually static), so there is no extra information that you would have to pull.

#7

This is true, but when we have pages with different “component” schemas injected into the page we then have to either loop through all the components, check for images then compile those accordingly. Or perhaps create a general regex or something to mass replace.

At the time, using X-ResolveUrls was much easier and efficient since we don’t need to do any compiling on the backend before sending to the frontend.

Either way, the root issue here is that a production feature was changed without warning or documentation or creating backwards combability.

We are slowly converting our projects to GraphQL, but please update if you plan to remove the X-ResolveUrls because we will have re-work how we process assets.

1 Like
#8

Sure…it was really not intended.

1 Like
#9

No worries :slight_smile: Keep us updated for future changes to this header

Have a good day!

1 Like
#10

@Sebastian

I found the documentation that would have to be changed to reflect the update
https://docs.squidex.io/02-documentation/developer-guides/api-overview/assets-api#using-headers-in-the-rest-endpoint

1 Like