XML downloads return HTTP 200 with “Request Rejected”

[carlos@agpsoftware.com]

Thank you for your suggestions and for confirming that our use of AntView looks correct.

We now have additional evidence:

- Manual XML downloads worked before starting the automated process.
- In our latest test, using a different public IP from the previous test, 66 XML downloads succeeded before the first rejection. The failure therefore does not consistently occur on download 19.
- Once the rejections started, manual downloads also failed in the browser, including when clicking the XML link directly on the notice page. Several different XML documents were affected.
- We then tested the same XML on a mobile phone: **it failed over the same Wi-Fi connection, but worked after switching to 5G**.

This strongly suggests a restriction associated with the public source IP, possibly triggered by request volume or frequency, rather than an AntView-specific issue. However, we cannot yet identify the exact rule.

In an earlier test, increasing the delays progressively to 60 seconds did not immediately restore access. A subsequent document was successfully downloaded on a retry approximately ten minutes after the first rejection.

We have reported these findings to the procurement platform’s support team and asked them to clarify their access restrictions and the supported approach for automated downloads.

We also plan to capture successful and rejected requests with Fiddler, as you suggested, to compare request and response headers, cookies, redirects and any diagnostic identifiers. Even if the restriction is IP-based, this should help us provide better evidence to their support team.

The rejected responses return HTTP 200 with an HTML “Request Rejected” page. Checking for an initial `<` character would therefore not distinguish them from XML; we need to validate the XML and its expected root element.

Thank you again for your help.