0

Our ASP.Net Core API, deployed on IIS in Windows 2019, reaches out and touches Shippo with upwards of 2500 requests an hour with tracking numbers, which had an issue on Thursday afternoon. Our API calls are initiated by 5 clients' middleware services, which run hourly 24/7. Our Shippo requests have been returning 404, even though Shippo has resolved the issue, and I can connect via Postman.

I am not a server administrator, but I have just enough knowledge to have tried the following: stopped then started IIS after a 10 second delay. Rebooted the machine. Took the API website offline for 90 minutes. Flushed the DNS cache on the IIS server, redeployed a slightly altered version of the webapi. And of course, it's a holiday weekend, and our managed IT provider has not gotten back to me. What should I attempt next while I wait?

Leah Hurst
  • 101
  • 1
  • 1
    This doesn't seem like a caching issue. Were you making modifications to the app or IIS config for troubleshooting? Perhaps a change was made and now the requests you are sending from IIS are invalid and returning a 404. I think you need to confirm that your request you are sending is, in fact, valid and confirm that the response is, in fact, a 404. You might need to look at logs, or write additional info to logs for the request/response content. The other possibility is that an upstream web filter/cache is caching the responses. Confirm by running postman from the web server. – Appleoddity May 28 '23 at 16:27
  • Postman from the server works. There have been no changes (prior to yesterday's troubleshooting) on that server for over a week, that I'm aware of. The issue started around the same time as Shippo's "degraded experience" is a causation guess. Every time this issue happens - each transaction - we get a database log table entry with the message and the call stack. This code worked for over 10 days, with no changes in web app config, IIS configuration (as far as I know - it's a managed IT hosted server). My guess is/was an upstream cache of some kind, or an IIS cache of some kind. – Leah Hurst May 28 '23 at 16:52
  • Or in the process of fixing the previous "degraded experience" they've changed something at their end, and that change means the URL you're using is no longer validso gets thr 404? – Keith Langmead May 28 '23 at 18:52

1 Answers1

0

Update: It was definitely related to the Shippo outage, but it was a coding issue. Our legacy code worked, and looked like this:

UriBuilder uribuilder = new UriBuilder(settings.url_base);
uribuilder.Path += "/tracks/";

The url that was being created referenced port 443 explicitly (https://api.goshippo.com:443)/, instead of the plain https://api.goshippo.com/ url, and I didn't notice that in the debugging until I'd decided to write an app to just query Shippo outside of our API. Apparently, Shippo made a setting change that no longer allowed the urls to reference port 443 directly (OR changed their port), around the time they resolved their issue. Once I set the url correctly, it worked. Thanks, Appleoddity and Keith Langmead for your assistance.

Leah Hurst
  • 101
  • 1