Inleiding van het document:De hyperlink-login is zichtbaar.
Toen ik de interface van de andere partij via curl aanriep, bleek dat het timeout-fenomeen erg ernstig was, dus vroeg ik het aan de interfacepersoon van de andere partij, en de andere partij zei dat het noodzakelijk was toe te voegen:
Na het toevoegen ontdekte ik dat het echt goed werkte, dus heb ik onderzocht hoe ik het kon gebruiken. Wanneer curl wordt gebruikt voor POST, wanneer "POST-data groter is dan 1024 bytes", zal curl geen direct POST-verzoek starten, maar wordt het verdeeld in 2 stappen:
Expect: 100-continue
1. Stuur een verzoek met een Expect:100-continue, waarin de server wordt gevraagd de data te accepteren
2. Na ontvangst van het 100-continue antwoord dat door de Server wordt teruggegeven, wordt de data POSTed naar de Server
Maar er zijn verschillende problemen hiermee:
Niet alle servers reageren correct op 100-continue, bijvoorbeeld lighttpd, wat 417 Expectation Failed teruggeeft.
waardoor vertraging ontstaat,Wanneer de client de eerste Expect:100-continue verzendt, moet hij wachten tot de server antwoordt voordat het request-lichaam wordt verzonden。
Als je zeker weet dat de server van de andere partij POST-verzoeken van meer dan 1024 bytes niet zal weigeren, kun je deze methode vermijden en de twee hierboven genoemde bijwerkingen vermijden; de oplossing is degene die aan het begin van het artikel wordt genoemd.
Ongeveer 100 gaan door
Het doel hiervan is om:
Het stelt de client in staat te beoordelen of de server bereid is de verzoekgegevens te ontvangen voordat hij deze verzendt, en als de server bereid is deze te ontvangen, zal de client de data daadwerkelijk verzenden.
Klantgedrag:
Een client die 100 continue stuurt, mag niet eeuwig wachten op een antwoord van de server, en na een tijdslimiet zou de client de entiteit direct moeten sturen.
Server-side gedrag:
Als de server een verzoek van 100 continue ontvangt, zal hij reageren met 100 continue of een foutcode sturen. De server kan nooit 100 continue sturen naar een client die geen 100 continue stuurt. Maar sommige servers wel. IIS 5 stuurt onjuist een 100-continue antwoord
Als de server het lichaam van de client ontvangt voordat hij de 100 continue response stuurt, betekent dit dat de client heeft besloten data te gaan verzenden, waardoor de server geen 100 continue meer naar de client kan sturen. De .NET Expect Off Expect Setting code is als volgt:
RestSharp is als volgt opgezet:
|