Issue with Sending Silent HTTP Data from PDF Form in Acrobat

[Riccardo Piga]

Hi everyone,

I am trying to send data (click tracking) from a PDF form via JavaScript in Adobe Acrobat, but without displaying any status or download window to the user. I’ve tried several solutions, but none have worked as expected.

Here’s what I’ve tried so far:

1. Using app.launchURL():
   I attempted using this method to send the data via a URL, but it opens the browser and causes user interaction (the browser asks for permission to open the URL), which is not ideal for my use case.

2. Using submitForm() (with GET and POST methods):
   I tried sending the data via both GET and POST methods using submitForm(), but Acrobat still triggers a download page or a status window, which interrupts the user experience. Despite trying to hide the button, the download page still appears.

3. Submit with Hidden Button and POST Method:
   I used a hidden button with submitForm() and tried POST, but it still causes Acrobat to open a download page, which is not what I need.

Earlier Attempts:

I also tried sending HTTP requests directly by constructing a string with app.launchURL() and Net.HTTP.request(), but those attempts failed to reach the server. The requests were not going through at all. However, when I manually pasted the same URL into a browser, it worked perfectly — the server responded and the data was logged.

Objective:

I need to send the data silently (without opening the browser or showing any download status) in a way that works reliably in both Acrobat Reader and Acrobat Pro. Ideally, this would happen in the background, without the user noticing.

It seems like this issue is specific to Acrobat, as the requests work fine when pasted directly into the browser.

Has anyone encountered similar issues or found a solution for silently sending HTTP requests from a PDF form in Acrobat? Any help would be greatly appreciated!

Thanks in advance!

[Thom Parker]

Acrobat is sandboxed for security. It does not allow direct access to the user's local file system, or web URLs that are not trusted. Acrobat has multiple levels of security and many options for secure operation. For example, one thing you can do is add a cross domain reference for the PDF.

Read this:

https://www.adobe.com/devnet-docs/acrobatetk/tools/AppSec/xdomain.html

However, most security issues rely on the local Acrobat settings, such as protected mode and the trusted sites list. 

Security can also be controlled though digital signatures. 

What it comes down to is that you can't access an URL silently unless there is a trust mechnanism in place to allow it. 

[Riccardo Piga]

Grazie mille per la risposta Thom.

Ti scrivo nella mia lingua per praticità, tanto puoi usare il traduttore.

Mi sembra di capire che per la mia situazione non c'è soluzione.

Io debbo distribuire il mio form ad utenti che utilizzeranno Reader e vorrei essere meno invasivo possibile.

Ho visto che con app.launchURL() e this.submitForm()  la stringa parte ma si apre una pagina browser che invece non vorrei far aprire.
Net.HTTP.request sarebbe l'approccio ideale ma mi stampa l'errore: ❌ Errore invio log: Net.HTTP is not a constructor

E' stano perchè al primo tentativo era correttamente partita la stringa, in modalità silenziona, anche se non aveva funzionato perchè lato server non c'era ancora la cartella di log, ed il server aveva generato il relatio errore. Dopo averla, creata, tuttavia, non c'è stato modo di inviatre nuovamente la stringa. 

[Riccardo Piga]

Thanks a lot for your reply, Thom.

I'm writing in my own language for convenience — you can just use a translator.

From what I understand, there’s no solution for my situation.

I need to distribute my form to users who will be using Reader, and I want to be as non-intrusive as possible.

I’ve seen that with app.launchURL() and this.submitForm(), the string is sent, but a browser window opens — which I’d prefer to avoid.
Net.HTTP.request() would be the ideal approach, but it gives the error: ❌ Error sending log: Net.HTTP is not a constructor.

It’s strange, because the first time I tried, the string was actually sent correctly in silent mode — although it didn’t work because the log folder didn’t yet exist on the server, and the server returned an error. But after creating the folder, I haven’t been able to send the string again.

[Thom Parker]

The Net.HTTP requires a privileged context, i.e., another security issue.  So it cannot normally be used from a script in a PDF

All the issues you are facing are result of Acrobat being very security concious. Data can be sent silently from a PDF, but the user has to somehow have explicitly allowed it to happen. 

[ava lily]

Anyone else run into issues when trying to send silent HTTP data from a PDF form in Acrobat? Everything seems set up correctly, but the data—like food order forms or other submissions—just isn’t submitting as expected—no errors, no alerts, just silence. If you’ve dealt with this before or have any workarounds, I’d really appreciate the insight!

[Riccardo Piga · Accepted solution]

For anyone interested, I finally found an instruction that allows sending a string silently from a PDF: it's SOAP.request, a deprecated function.

Although it throws an error in the JavaScript console, it still works and successfully pings the server without opening a browser window or changing the Acrobat view — truly silent.

The only limitation: it only works in Acrobat Pro, not in Reader.

If anyone manages to get it working in Reader too, that would be the real game-changer.

[Thom Parker]

This is not a viable solution. 

Soap, while it doesn't require privilege to operate, like the HTTP request, it does require form rights.  The term "Form Rights" is ambigous because there are several different types of form rights, and the reference isn't specific.  Some form rights are given freely now (but weren't in the past), and some require a special purchase from Adobe.  This can all change.

The SOAP object is not really depricated, just moved, so it's still there. And it doesn't work in Reader supossidly because Reader simply doesn't contain the code to do it. If so, then there is no way to "get it to work", because it's just not there.   

[Riccardo Piga]

For anyone interested, here are the results of 5 isolated tests I performed in Acrobat Reader using 5 different methods to ping an endpoint:

Tested methods:
01 – Net.HTTP
02 – submitForm
03 – app.launchURL
04 – doc.getURL
05 – SOAP.request

Results summary (from Reader):

Method Ping Sent ! Browser Page Opened ! Acrobat Page Opened

01 – Net.HTTP	❌	❌	❌
02 – submitForm	✅	❌	❌
03 – launchURL	✅	✅	❌
04 – getURL	✅	✅	❌
05 – SOAP	❌	❌	❌

Conclusion:

For the purpose of this thread (a truly silent ping from Reader), scenario 02 (submitForm) would be ideal — if it weren’t for the system alert (here attacched) that appears when the request is completed. The ping is sent, no page is opened, but a modal system message still interrupts the user.
If anyone finds a way to suppress or avoid that system alert, that would be the holy grail. 🙏

[Thom Parker]

I applaude your efforts in testing the limits of internet operations from a PDF, but suppressing security messages to the user from an operation on an untrusted radom PDF, would probably be an Acrobat Security violation.