Your achievements

Level 1

0% to

Level 2

Tip /
Sign in

Sign in to Community

to gain points, level up, and earn exciting badges like the new
Bedrock Mission!

Learn more

View all

Sign in to view all badges

SOLVED

AEM 6.5 Assets Http Api - 404 error for tif assets

Avatar

Level 4

Hi All,

I have written a python script to update one of the property for all assets under a folder using assets http api. It's a PUT request to update the property. The script works fine for PNGs, PDFs but not for tif assets, it is throws a Resource Not Found, 404 error.

For example: http://localhost:4502/api/assets/skm-local/Capture.PNG works and I get 200 back. But http://localhost:4502/api/assets/skm-local/test.tif does not work and I get 404 return. I get the same result when I try this requests in postman.

 

Even the GET requests via postman return the same results for above URLs. The png gets returned fine but for tif I get 404. Is this a expected behavior for tif files? Does assets http api not support tif formatted assets?

 

Thanks & Best Regards,

SKM

1 Accepted Solution

Avatar

Correct answer by
Employee

This works just fine on AEM 6.5.6 for me.

Try issuing these Curl commands (updating user/pass, path as needed)

 

  • curl --user admin:admin http://localhost:4502/api/assets/test.jpeg -X PUT -H"Content-Type: application/json" -d '{"class":"asset", "properties":{"dc:title":"My JPEG"}}'
  • curl --user admin:admin http://localhost:4502/api/assets/test.tiff -X PUT -H"Content-Type: application/json" -d '{"class":"asset", "properties":{"dc:title":"My TIFF"}}'
  • curl --user admin:admin http://localhost:4502/api/assets/test.tif -X PUT -H"Content-Type: application/json" -d '{"class":"asset", "properties":{"dc:title":"My TIF"}}'

 

http-assets-api-tif.png

 

If you are able to download the original rendition and open it (showing there is nothing wrong with streaming the bits off the original rendition JCR node) then im not sure ... Since you can update other Tiff's it sounds like there is something weird w/ this Tif's manifestation in AEM. You could try re-uploading the downloaded orginal as a NEW asset and see if that asset has the same problem. If so, maybe there is something w/ that tiff? All and all, HTTP Assets API supports PUT requests for Tif's. If you need to understand why this specific Tif is misbehaving, Adobe Support should be able to help you dig deeper.

 

View solution in original post

23 Replies

Avatar

Correct answer by
Employee

This works just fine on AEM 6.5.6 for me.

Try issuing these Curl commands (updating user/pass, path as needed)

 

  • curl --user admin:admin http://localhost:4502/api/assets/test.jpeg -X PUT -H"Content-Type: application/json" -d '{"class":"asset", "properties":{"dc:title":"My JPEG"}}'
  • curl --user admin:admin http://localhost:4502/api/assets/test.tiff -X PUT -H"Content-Type: application/json" -d '{"class":"asset", "properties":{"dc:title":"My TIFF"}}'
  • curl --user admin:admin http://localhost:4502/api/assets/test.tif -X PUT -H"Content-Type: application/json" -d '{"class":"asset", "properties":{"dc:title":"My TIF"}}'

 

http-assets-api-tif.png

 

If you are able to download the original rendition and open it (showing there is nothing wrong with streaming the bits off the original rendition JCR node) then im not sure ... Since you can update other Tiff's it sounds like there is something weird w/ this Tif's manifestation in AEM. You could try re-uploading the downloaded orginal as a NEW asset and see if that asset has the same problem. If so, maybe there is something w/ that tiff? All and all, HTTP Assets API supports PUT requests for Tif's. If you need to understand why this specific Tif is misbehaving, Adobe Support should be able to help you dig deeper.

 

Avatar

Employee
What exact version of AEM are you on? Can you try moving to 6.5.6 if you are not on it?

Avatar

Employee

Also - can you ensure you can perform a GET on it (to read it) and ensure your used has permissions to write to that node. (If youre testing with admin/admin then obviously you have permissions).

Can you provide a screenshot show that your user can read the node at: /content/dam/skm-local/test.tif in AEM?

Avatar

Level 4
I am on 6.5.6.0. I am using the same account admin:admin to access the Capture.PNG in the same folder. I will upload the screenshot of list view to show the both.

Avatar

Level 4
I have uploaded the screenshot. The get request via postman also returns the 404 for tif assets.

Avatar

Employee
Sorry - dont see the screenshot? Maybe something weird with ExL Communities?

Avatar

Employee

Sorry - dont see the screenshot? Maybe something weird with ExL Communities? Can you also check OSGi console and review the PUT in your recent requests? The HTTP Assets API does some resource wrapping ..not sure if there are any hints in there for you? Mine looks like:

davidjgonzalezz_0-1603989013514.png

 

Avatar

Level 4
There are 3 answers to this topic, one originally by you and two by me. I have the screenshots in the two answers. May be click on "View Entire Topic" to see the additional answers.

Avatar

Employee

Ok - sorry, I missed the other posts outside this thread. So this might sound weird - but can you try a smaller tif file? I used the 1MB one from here: https://file-examples.com/index.php/sample-images-download/sample-tiff-download/


Also, can you check in CRXDE Lite to make sure that /content/dam/skm-local/test.tif/jcr:content/renditions/original/jcr:content exists?

 

If that node doesn't exist (or isn't readable) then the AssetResource cannot be instantiated and it will appear as if the resource is not found.

Avatar

Level 4

Looks like we on to something, so the curl command works fine for a 1mb tif file. But the original tif file is 146mb and I verified that original rendition does have content. Screenshot below:

skmAem_0-1603991809626.png

 

Avatar

Level 4
I wonder if that particular tif file is corrupt or something. I tried with another large tif file of 189mb and the curl command worked just fine.

Avatar

Employee
Can you try downloading the misbehaving tif's original rendition?

Avatar

Level 4
Hello David, Sorry for late response but I was able to download the original rendition successfully.

Avatar

Employee
If you are able to download the original rendition and open it (showing there is nothing wrong with streaming the bits off the original rendition JCR node) then im not sure ... Since you can update other Tiff's it sounds like there is something weird w/ this Tif's manifestation in AEM. You could try re-uploading the downloaded orginal as a NEW asset and see if that asset has the same problem. If so, maybe there is something w/ that tiff? All and all, HTTP Assets API supports PUT requests for Tif's. If you need to understand why this specific Tif is misbehaving, Adobe Support should be able to help you dig deeper.

Avatar

Level 4

Hi @davidjgonzalezz ,

Thanks for your quick response. I tried the sample curl commands and I still get the 404 for tif file. I am on 6.5.6.0. Here are the commands and outputs from a terminal:

 

$ curl --user admin:admin http://localhost:4502/api/assets/skm-local/test.tif -X PUT -H"Content-Type: application/json" -d '{"class":"asset", "properties":{"dc:title":"My TIF"}}'

{"class":["core/response"],"properties":{"path":"/api/assets/skm-local/test.tif","parentLocation":"/api/assets/skm-local.json","referer":"","changes":[],"location":"/api/assets/skm-local/test.tif.json","status.message":"No resource found at /api/assets/skm-local/test.tif","status.code":404}}

 

 

$curl --user admin:admin http://localhost:4502/api/assets/skm-local/Capture.PNG -X PUT -H"Content-Type: application/json" -d '{"class":"asset", "properties":{"dc:title":"My TIF"}}'

{"class":["core/response"],"properties":{"path":"/api/assets/skm-local/Capture.PNG","parentLocation":"/api/assets/skm-local.json","referer":"","changes":[{"argument":"/api/assets/skm-local/Capture.PNG","type":"modified"}],"location":"/api/assets/skm-local/Capture.PNG.json","status.message":"OK","title":"Content modified /api/assets/skm-local/Capture.PNG","status.code":200}}

 

tifIssue.png

 

Thanks,

SKM