HTTP 504 Gateway Timeout versus de time-out van je client

Je client is bereid zestig seconden te wachten. Tien seconden later ontvangt hij HTTP 504. De time-out van de client verhogen naar twee minuten geeft de gateway geen vijftig seconden extra werk.

504 beschrijft een gateway of proxy die tijdens het afronden van het verzoek geen tijdige upstreamreactie ontving. De gateway heeft zijn beslissing al genomen en een reactie teruggegeven. Je client kan die reactie zonder problemen lezen.

Welke tussenlaag heeft hem teruggestuurd?

De forwardproxy kan de afzender zijn. Ook een latere gateway die door de website wordt beheerd. Met gewone end-to-end-TLS binnen CONNECT is een HTTP-reactie uit die beschermde uitwisseling met de bestemming niet hetzelfde als een weigering van CONNECT zelf.

Bewaar de fase, de responsheaders, de formulering van de foutpagina en de bijbehorende logs waar beschikbaar. Een servernaam kan een aanwijzing zijn, maar mag niet als onfeilbare toewijzing gelden. De route kan meer tussenlagen bevatten dan degene die in je client is geconfigureerd.

Onderzoek daarna waarom die upstreambewerking niet is voltooid. Bereikbaarheid, overbelaste diensten, een verzoeklichaam dat de upstream niet verwacht kan verwerken, en toepassingsgedrag kunnen allemaal meespelen. De numerieke status alleen bewijst niet dat een andere User-Agent of één extra time-outoptie de universele oplossing is.

Vergelijk hetzelfde verzoek

Als een ander hulpmiddel werkt, vergelijk dan methode, doel, lichaamscodering, authenticatie en route. "De URL opent in een browser" is geen volledige vergelijking met een multipart-inzending via een serviceclient.

Beheer je de verzendende gateway, stem zijn upstreambudget dan af op de ondersteunde werklast en de omliggende deadlines. Zo niet, bewaar het resultaat als bewijs en gebruik het gedocumenteerde toegangs- of ondersteuningspad van de operator. Langer lokaal wachten kan een antwoord dat al binnen is niet veranderen.