Problema cuando el PDF es generado utilizando parámetros enviados por POST

​Hi @smooth_Walrusd9bc 

Hope you are doing well, and thanks for reaching out. We are sorry for the trouble you are experiencing. 

We recently released version 26.8.1.5 of the Acrobat Chrome extension to the Chrome Web Store, which contains a fix for this behavior. Could you please update to version 26.8.1.5 and let us know if the issue is resolved?

To update the extension manually:

1. Go to chrome://extensions in your Chrome browser.

2. Toggle on Developer mode in the top-right corner.

3. Click the Update button at the top left.

4. Verify that the Acrobat extension shows version 26.8.1.5.

If the issue persists after updating, please share the latest HAR logs with us so we can investigate further. Additionally, we would be happy to schedule a quick call or screen-sharing session to better understand your environment and work directly toward a resolution. Please let us know a time that works best for you.

Thank you again for your time and patience. We look forward to hearing from you.

 ~Amal

Hi Anand, thanks for the response. Here are the details:

Chrome version: 151.0.7922.75 (Official Build) (x86_64)
Extension: Adobe Acrobat: PDF edit, convert, sign tools
Extension version: 26.8.1.5
Extension ID: efaidnbmnnnibpcajpcglclefindmkaj

Do you have the Acrobat/Reader desktop app installed? No, I don't have any Acrobat or Reader desktop application installed. I only use the Chrome extension.

PDF origin: The PDF is generated dynamically (on the fly) on the server, from a POST request with parameters (for example, an endpoint that receives form data and returns the resulting PDF with Content-Type: application/pdf, without Content-Disposition: attachment, i.e., served inline).

Technical description of the bug:
When the PDF is requested as a full-page navigation (main_frame), the extension intercepts the response and redirects to chrome-extension://efaidnbmnnnibpcajpcglclefindmkaj/viewer.html?pdfurl=<URL>. That viewer.html re-requests the resource, but does so with a plain GET to the URL, without the body or data that traveled in the original POST request. Since the server needs those POST parameters to generate the PDF, the second request (GET, no body) fails to generate the file correctly, and the result is an error.

How we confirmed this:
We verified that when the same PDF is displayed inside an embedded <iframe> (instead of a full-page navigation), Chrome treats the load as sub_frame, the extension does not intercept it, and the PDF is displayed correctly by the native viewer (with the extension only offering an optional icon to open it in Acrobat). This confirms the issue is specific to main_frame interception combined with POST requests.

Attached screenshots:

• Chrome console showing the errors when trying to load the PDF via POST (net::ERR_FAILED, "Denying load...")
• Comparison: the same PDF working correctly inside an iframe

Impact: This bug affects any system that generates PDFs dynamically via POST (reports, receipts, invoices, etc. with parameters). We have approximately 1500 download points affected in our system, and it is not feasible to modify each one individually — we would need the extension to either respect the original request method/body, or provide a way to exclude certain domains/paths from automatic interception.

I remain available for any additional testing you may need.

Best regards.