Extension: Adobe Acrobat: PDF edit, convert, sign tools (ID: efaidnbmnnnibpcajpcglclefindmkaj)Browser: Google Chrome 151.0.7922.72The same setup worked correctly on Chrome versions prior to 151.0.7922.72, with no changes on our server side.Our web application generates PDF reports and returns them inline (Content-Type: application/pdf) as the direct response to an HTML form submitted via POST (method="post", target="_blank"). Since updating to Chrome 151.0.7922.72, printing these reports through the Acrobat extension's viewer fails with a "page not found" (404) error. PDFs served in response to a plain GET request/link are unaffected — only PDFs returned as the response to a POST form submission fail. Steps to reproduce:Enable the Adobe Acrobat extension in Chrome 151.0.7922.72. Submit an HTML form (method="post") whose server response is a PDF served inline (no Content-Disposition: attachment header). The new tab shows a "404 / page not found" error. For comparison, opening the same kind of report via a plain GET link works fine. It appears the extension performs a secondary fetch of the report's URL (instead of reusing the bytes from the original POST response) in order to render/print it in its own viewer, and this secondary fetch is a GET request. Since our server endpoint only accepts POST for this route, the extension's GET replay doesn't match any route and the server correctly returns 404. This is consistent with GET-triggered PDFs working fine, since both the original request and any replay are GET.Impact: any print action on our platform served via a POST-submitted form and rendered as an inline PDF fails for users with this extension enabled, forcing us to instruct affected users to disable the extension as a workaround.

Participant

Question

Adobe Acrobat Chrome extension returns 404 when printing PDFs served via POST form submission (regression in Chrome 151.0.7922.72)

Forum|Forum|1 day ago
July 30, 2026
4 replies
22 views

Extension: Adobe Acrobat: PDF edit, convert, sign tools (ID: efaidnbmnnnibpcajpcglclefindmkaj)
Browser: Google Chrome 151.0.7922.72

The same setup worked correctly on Chrome versions prior to 151.0.7922.72, with no changes on our server side.

Our web application generates PDF reports and returns them inline (Content-Type: application/pdf) as the direct response to an HTML form submitted via POST (method="post", target="_blank"). Since updating to Chrome 151.0.7922.72, printing these reports through the Acrobat extension's viewer fails with a "page not found" (404) error. PDFs served in response to a plain GET request/link are unaffected — only PDFs returned as the response to a POST form submission fail.

Steps to reproduce:

Enable the Adobe Acrobat extension in Chrome 151.0.7922.72.
Submit an HTML form (method="post") whose server response is a PDF served inline (no Content-Disposition: attachment header).
The new tab shows a "404 / page not found" error.
For comparison, opening the same kind of report via a plain GET link works fine.

It appears the extension performs a secondary fetch of the report's URL (instead of reusing the bytes from the original POST response) in order to render/print it in its own viewer, and this secondary fetch is a GET request. Since our server endpoint only accepts POST for this route, the extension's GET replay doesn't match any route and the server correctly returns 404. This is consistent with GET-triggered PDFs working fine, since both the original request and any replay are GET.

Impact: any print action on our platform served via a POST-submitted form and rendered as an inline PDF fails for users with this extension enabled, forcing us to instruct affected users to disable the extension as a workaround.

FernandossddAuthor

Participant

I’ve already tried the steps you indicated but without success.

About the questions:

1. The application triggers a POST, and the Adobe extension doesn't open the PDF from that response — instead, it re-fetches the resource as a GET request, which causes the error. We've verified on our server logs that both the original POST and the subsequent GET from the extension are received.

2. Yes. Several of our clients reported this issue independently, and in every case it started right after the new Chrome update released on 07/29 (July 29) — no reports before that date. That's when we started advising affected clients to disable the extension as a workaround. Our own team was also able to reproduce the problem directly in our test environment, confirming it only happens on Chrome 151.0.7922.72 and later.

3. No.

4. Windows.

Amal Jaiswal

Community Manager

Hi @Fernandossdd ,

Thanks for the detailed follow-up and for confirming this at the server-log level that's very helpful.

To summarize what you've found so we're all aligned:

Root cause behavior: the extension isn't reusing the bytes from the original POST response. Instead, it issues a secondary GET request to the same URL to load the PDF into its own viewer. Since your endpoint only accepts POST on that route, the GET replay 404s while your logs confirm both the original POST and the extension's follow-up GET are hitting your server as expected.
Regression window: multiple independent client reports, all starting immediately after the Chrome update on July 29, with no prior reports. You've also reproduced it directly in your test environment, and confirmed it's isolated to Chrome 151.0.7922.72 and later (with earlier versions unaffected).

Given that isolation, this does look like a change in how the extension (or Chrome itself) handles the "reload as GET to render/print" step for POST-originated inline PDF responses, it's possible that a prior version preserved the POST body/method on that internal re-fetch, and 151.0.7922.72 changed that behavior (e.g., now always issuing a GET regardless of the original method).

A few things that would help move this toward a fix:

A minimal repro (a tiny form + server route that returns a PDF inline on POST) would let engineering confirm the exact request the extension issues on the secondary fetch, headers, method, and whether it's the extension's background script or Chrome's PDF viewer plumbing doing the re-fetch.
If you're able to capture a HAR file from chrome://net-export (or DevTools Network tab) showing the original POST and the subsequent 404'd GET, that would give the team concrete evidence of the exact call being made.
It'd help to know whether this happens with the extension's viewer only, or also when "Open PDFs in the default viewer" style settings are toggled,that'll narrow down whether the fix belongs in the extension or upstream in Chrome's handling of extension-based PDF viewers.

In the meantime, disabling the extension is a reasonable interim workaround for affected users, as you've already advised. I'd also suggest filing this directly through the in-product feedback option in the extension (or via the Acrobat bug report form https://adobe.ly/4vZvxUO) referencing this thread, since server-side route/method mismatches triggered by extension behavior are the kind of thing that needs to go to the engineering team handling the Chrome extension.

I'll flag this thread internally as well. Appreciate you doing the legwork to isolate the exact Chrome version.

~Amal

FernandossddAuthor

Participant

Hi Amal,

Following up with the minimal repro you requested. It's live at:

https://nodejs-production-a1f8.up.railway.app/

It reproduces the exact pattern from our production app:

The page has a form with method="POST" (target="_blank"), matching how our real report actions work.
Submitting it returns a PDF inline (Content-Type: application/pdf, no Content-Disposition) — this route only accepts POST.
A GET request to that same endpoint returns a 404 by design, since there's no GET handler — this is what the extension's secondary fetch hits.

To reproduce: open the URL in Chrome 151.0.7922.72+ with the Acrobat extension enabled, click the button to generate the PDF, then try printing it from within the extension's viewer.

If you disable the extension it will print without issues

We'll keep this test instance up for the next few weeks while your engineering team investigates.

Thanks,
Fernando

Amal Jaiswal

Community Manager

Hi @Fernandossdd ,

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

Please answer a few quick questions for more understanding:

Can you confirm whether the 404 only happens on the print action triggered from within the Acrobat extension viewer, or does it also happen when the extension first intercepts and renders the PDF in the new tab?
Are you seeing the same behavior across multiple machines on Chrome 151.0.7922.72, or is this isolated to one device so far?
Is your server returning any X-Frame-Options or Content-Security-Policy headers on the POST response that could affect how the extension re-fetches the resource?
What OS are you on (Windows/macOS)?

Please try the steps below and see if that works:

Option 1: Adjust Chrome's PDF handling settings

This is the first thing to try, as it can prevent the extension from attempting a secondary GET fetch altogether:

Go to chrome://settings/content/pdfDocuments in your Chrome address bar, then under "Default behavior" select "Open PDFs in Chrome." Reload and try printing again. Please check Adobe's official guidance for this here: Fix browser extension PDF printing issues.

Option 2: Temporarily disable the Acrobat extension

Go to chrome://extensions, find "Adobe Acrobat: PDF edit, convert, sign tools," and toggle it off. Chrome's native PDF viewer will then handle the POST response directly without the secondary GET replay. Let us know how it goes. For more information about managing the extension, please check the page: Enable Adobe Acrobat extension for Google Chrome.

Option 3: Reinstall the extension

A fresh install has resolved similar GET-replay behavior for other community members in the past. Go to chrome://extensions, remove the Acrobat extension entirely, then reinstall it from the Chrome Web Store. Retest the POST-triggered PDF print flow after reinstalling.

Let us know how it goes.

~Amal

Sign up

To post, reply, or follow discussions, please sign in with your Adobe ID.

Sign in to Adobe Community

To post, reply, or follow discussions, please sign in with your Adobe ID.