Adobe Acrobat Chrome Extension doing multiple calls

Report · Sep 06, 2022

We have an online application that is limiting the PDF download to only once. We've found that users have been complaining of the attachment not being downloadable. Further investigation showed that the issue is only happening when users are accessing their PDF via Chrome with the Adobe Acrobat Extension. From what it looks like, the extension is doing multiple calls to the file thus resulting to the file not being accessible due to the limit. Can you please check on this and see what can be done to mitigate such problems. The only solution we ahve so far is to have users uninstall the extension and try to download their file again.

Report · May 09, 2025

Hi Meenakshi, the file is restored as of 830a ET today

Report · May 09, 2025

Hi Vertifi,

We did check, but it seems the file is not there. The link opens with a 404 error.

Please let us know if you have removed the file.

Thanks,

Meenakshi

Report · May 09, 2025

From one of Vertifi's previous posts:
"We've observed the Adobe Acrobat Chrome Extension (v25.4.2.2) double-fetching the content, this leads to a user-facing 404 error."

Opening the link on Chrome with the Adobe Acrobat extension would lead to a 404 error. Next test, try opening the link with a different browser or with the extension uninstalled.

Report · May 09, 2025

Hi Meenakshi, sorry staging for thsi test is challenging for us as any content we place on this site automatically deletes after 20 minutes or so ... I need to continuously refresh to keep it from purging.

With that said I did restore the file at around 1235p ET and do see you fetched it, with indications that the issue has been reproduced.

These are web server audit logs, the first two lines show back-to-back requests arriving at 16:44:57 UTC (1244p ET), the first one responded with HTTP 200 and the content, the second with HTTP 404. Then 2 seconds later at 16:44:59 UTC a subsequent pair of requests both of which failed with HTTP 404 because the file is automatically deleted after any successful fetch.

2025-05-09 16:44:57 W3SVC2 WS-TN2 192.168.101.129 GET /files/reports/test.pdf - 443 - 130.248.112.29 HTTP/2.0 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/135.0.0.0+Safari/537.36 - - test.vertifi.com 200 0 0 115200 715 893
2025-05-09 16:44:57 W3SVC2 WS-TN2 192.168.101.129 GET /files/reports/test.pdf - 443 - 130.248.112.29 HTTP/2.0 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/135.0.0.0+Safari/537.36 - - test.vertifi.com 404 0 0 1486 554 281
2025-05-09 16:44:59 W3SVC2 WS-TN2 192.168.101.129 GET /files/reports/test.pdf - 443 - 130.248.112.29 HTTP/2.0 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/135.0.0.0+Safari/537.36 - - test.vertifi.com 404 0 0 1486 695 296
2025-05-09 16:44:59 W3SVC2 WS-TN2 192.168.101.129 GET /files/reports/test.pdf - 443 - 130.248.112.29 HTTP/2.0 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/135.0.0.0+Safari/537.36 - - test.vertifi.com 404 0 0 1486 695 282

Report · May 09, 2025

Hey Vertifi,

Thank you for the information.

Please allow us some time to check this with the team once. If necessary, we can connect to look at what is happening. We will let you know if more information is required.

We appreciate your patience.

Thanks,

Meenakshi

Report · May 09, 2025

Hi Meenakshi,

This might be helpful: I noticed that the IP address (130.248.112.29) in the logs that Vertifi posted traces back to Adobe Systems India Pvt. Ltd in Noida, India, which I'm guessing proves that the request came from.

Report · May 09, 2025

@ryan_7369 is correct, and our log info shows the exact circumstance we've been seeing, double-fetches with the Chrome extension enabled.

And just a reminder, a back-end change whereby we enable client caching for a small time window of the content does appear to work around this problem, though not ideal. With this we still see the double fetches in our logs but the content from the first fetch is rendered and the user doesn't see the 404 error. I'll be restoring this workaround on our test environment, but can reset for further testing as needed.

Report · May 09, 2025

Hi Meenakshi, I've attached here a Chrome Network log (from Developer Tools), this is their "HAR" file. I believe you'll see clear evidence here from the browsers perspective of the multi-fetching occurring.

Also I'm now seeing my previous workaround not working which is very worrisome.

Report · May 12, 2025

Hi Vertifi,

Thank you for the HAR file. It will be helpful.

We will update you once we get any information from the team.

Thanks,

Meenakshi

Report · May 21, 2025

Hi Vertifi,

Thank you for your patience.

As per the current Extensions architecture, we do not support one-time URLs. However, the team would like to check why the workaround you mentioned above is not working.

Please let us know if we can schedule a session with you and our team to investigate further. If yes, please share the active email address where we can send the invite and the time frame when you will be available for the session.

You may share the details in a private message using the envelope icon at the top right corner of this community page.

Thanks,

Meenakshi

Report · May 21, 2025

Hi Meenakshi, I have messaged you with my contact info and availability, I'd very much like to find a workaround.

Regarding this seemingly new position "we do not support one-time URL's", this is very unfortunate and I'd like to provide reasons why Adobe should reconsider:

one-time URL's used for security. Dynamically generate PDF's with sensitive content should only be fetched a single time
customer billing. Companies may create PDF content that is billable, and use fetch counts to determine billing. If the extension causes double fetching then billing won't be accurate
usability/supportability. Our product works perfectly with Edge and Chrome and other browsers. Its only when the Adobe Chrome browser extension is installed that we have failures, i.e. you have caused a regression
bandwidth/efficiency. Fetching the same PDF content multiple times from a server is inefficient, particularly with large files. This is bad for the server and the client.

Until resolved we're forced to instruct our clients to remove the Adobe extension

Report · May 21, 2025

Hi Vertifi,

Thank you for sending the details. We have received your message.

We will share the timings to confirm before scheduling the session.

Thanks,

Meenakshi

Report · May 21, 2025

>As per the current Extensions architecture, we do not support one-time URLs.

The Adobe Acrobat Extension on Edge currently supports the use of one-time URLs. I again tried to open a one-time PDF with the Edge extension (version 25.5.1.0, which is the exact same version number as the Chrome extension), and it worked perfectly.

My company has also instructed customers to remove the Adobe Acrobat extension in Chrome due to this issue.

Report · May 22, 2025

Hi ryan_7369,

Thank you for the information. We will share the information with the team.

The team will be looking into this behavior.

Thanks,

Meenakshi

Report · Aug 28, 2025

While we observed this corrected for some time this year (2025), with version 25.8.2.1 this very troublesome flaw seems to have returned in the Chrome extension. This flaw does not exist in the same version on Edge.

I hope this gets some attention and gets corrected once and for all, this is very frustrating for our users