Unsere ASP.Net Core API, die auf IIS in Windows 2019 bereitgestellt wird, erreicht Shippo mit über 2500 Anfragen pro Stunde mit Trackingnummern, bei denen es am Donnerstagnachmittag ein Problem gab. Unsere API-Aufrufe werden von den Middleware-Diensten von 5 Clients initiiert, die stündlich rund um die Uhr laufen. Unsere Shippo-Anfragen haben 404 zurückgegeben, obwohl Shippo das Problem behoben hat und ich mich über Postman verbinden kann.
Ich bin kein Serveradministrator, aber ich habe gerade genug Wissen, um Folgendes versucht zu haben: IIS gestoppt und nach einer Verzögerung von 10 Sekunden wieder gestartet. Den Rechner neu gestartet. Die API-Website 90 Minuten lang offline genommen. Den DNS-Cache auf dem IIS-Server geleert und eine leicht veränderte Version der WebAPI neu bereitgestellt. Und natürlich ist heute ein Feiertagswochenende und unser Managed-IT-Anbieter hat sich nicht bei mir gemeldet. Was soll ich als Nächstes versuchen, während ich warte?
Antwort1
Update: Es hing definitiv mit dem Shippo-Ausfall zusammen, aber es war ein Codierungsproblem. Unser Legacy-Code funktionierte und sah so aus:
UriBuilder uribuilder = new UriBuilder(settings.url_base);
uribuilder.Path += "/tracks/";
Die erstellte URL verwies explizit auf Port 443 (https://api.goshippo.com:443)/, anstelle des einfachenhttps://api.goshippo.com/URL, und das ist mir beim Debuggen erst aufgefallen, als ich mich dazu entschlossen hatte, eine App zu schreiben, die Shippo einfach außerhalb unserer API abfragt. Offenbar hat Shippo eine Einstellungsänderung vorgenommen, die es den URLs nicht mehr erlaubte, direkt auf Port 443 zu verweisen (ODER ihren Port geändert), ungefähr zu der Zeit, als sie ihr Problem gelöst hatten. Nachdem ich die URL richtig eingestellt hatte, funktionierte es. Danke, Appleoddity und Keith Langmead, für eure Hilfe.