Hi Michael,

1. Sanity check that the requests from Workflow are not first routed through an outbound proxy appliance. If so, it's possible the authentication error is coming from the outbound proxy intercepting the request. Make no assumptions here. I've worked on more than a few support cases where the issue turned out to be a "surprise" forward proxy intercepting outbound web requests that the customer's Laserfiche admins had no idea existed.
    
2. There are a few ways to investigate if there's a forward proxy in play:
   1. Ask the customer's networking/security team if there's a forward/outbound HTTP proxy in use that could potentially apply to traffic coming from the Workflow server.
   2. Inspect the "Server" HTTP response header of the failed calls and check for any values that might indicate they're coming from a web server you don't expect.
   3. Ask the vendor hosting the software to pull their web server logs around the timestamp (+- a few seconds) and confirm if their services sent that HTTP response or not. If there's no record of them sending the response, that's a good (not definitive) indication the request never made it to them, likely because something in the middle intercepted it.
       
3. If they do have a record of sending the response in their web server log, you should push them on why their service is returning HTTP 403 Forbidden responses with "<Code>AuthenticationFailed</Code><Message>Server failed to authenticate the request." if "there are no authentication requirements".
   1. Bluntly, when there are no authentication requirements, servers do not typically return a HTTP 403 Forbidden with a response body containing "AuthenticationFailed" error codes explicitly stating that they failed to authenticate a request. 
       
4. The statement "since it works in a browser there's nothing on [the hosting vendor] end that would be stopping this" is not a valid claim whatsoever. Modern browsers are incredibly complex pieces of software that handle many, many things for you behind the scenes. This service may have implicit dependencies on browser behavior whoever you're talking to isn't aware of.
    
5. You should try to reproduce the issue using a different and standard headless/non-browser HTTP request method, such as Postman, curl, or the PowerShell Invoke-WebRequest (for HTML) or Invoke-RestMethod (for XML/JSON) (note 1, note 2) commands. This completely removes Laserfiche from the equation and replaces it with a widely used, freely available, industry standard method of making headless HTTP requests.
   1. Try this first from the same machine that's running Workflow.
   2. If the issue is reproducible there, next try reproducing it from a client machine on the same network rather than a server.
   3. If the issue is still reproducible there, next try reproducing it from a client machine on an entirely different network.
   4. If the issue is still reproducible there, you have more than enough evidence to open a bug report/support case with the vendor. Send them the Postman/curl/PowerShell/etc. script you used to reproduce the issue along with the test cases and logs with the requests and responses for each, and request they attempt to reproduce the issue on their end.

Hopefully that gives you some leads to further troubleshoot the matter.

Thanks Sam.

I had the client IT check and they're not filtering or routing through an outbound proxy. And that seems to align with the fact that I can get some of the documents to download via the workflow activity, just not others. 

I'm working to get the vendor to check the logs on the server to report back what they are seeing. I did as you asked testing outside of Workflow via the Powershell Invoke-WebRequest from the client server, and that's working as expected, I'm able to successfully download the file. 

At this point, the only failure I am seeing is when Workflow's HTTP Web Request Activity tried to get some of the files. Any thing else you can think of?

Thanks Brian. So if there is an issue with 'escaping or not escaping some characters', do you have a suggestion about how I could go about resolving that?  From what I'm seeing, things should already be encoded, and I've tried decoding via the workflow function with no changes. 

This is the tail end of a URL that successfully downloads:

2024.02.01_Glade_Spring_Crossing_Prelim_Plat-sealed_Thu_Feb_1_2024_13-40-39.pdf?st=2024-02-01T19%3A00%3A29Z&se=2025-01-31T19%3A00%3A29Z&sp=r&sv=2018-03-28&sr=b&sig=dwLaqZBLyLFW946hTeUw1rqmaXlpz9Y%2FVsOku9pXBMU%3D

And this is the tail end of a URL that fails: 

18%232596-2024-09-10T12%3A00%3A42%2B00%3A00.pdf?st=2024-09-10T12%3A00%3A42Z&se=2025-09-10T12%3A00%3A42Z&sp=r&sv=2018-03-28&sr=b&sig=8nf45XvWxTAfJTH1TSNcKRz%2BsUMnhLEBhz99cQmuSMQ%3D

Anything else earlier in the URL is identical and would not be sharable as it's client identifiable and would allow anyone to download the documents. I hope this helps identify something as they look pretty similar to me.