Asiakirjan esittely:Hyperlinkin kirjautuminen on näkyvissä.
Kun kutsuin toisen osapuolen käyttöliittymää curlin kautta, huomattiin, että aikakatkaisuilmiö oli hyvin vakava, joten kysyin toisen osapuolen käyttöliittymähenkilöltä, ja toinen osapuoli sanoi, että on tarpeen lisätä:
Lisättyäni sen huomasin, että se toimi todella hyvin, joten aloin tutkia, miten sitä käytetään. Kun curlia käytetään POSTissa, kun "POST-data on yli 1024 tavua", curl ei suoraan käynnistä POST-pyyntöä, vaan se jaetaan kahteen vaiheeseen:
Expect: 100-continue
1. Lähetä pyyntö, joka sisältää Expect:100-continue-viestin, pyytäen palvelinta hyväksymään tiedot
2. Kun palvelimen palauttama 100-jatko-vastaus on saatu, data POSToidaan palvelimelle
Mutta tässä on useita ongelmia:
Kaikki palvelimet eivät reagoi oikein 100-jatkoon, esim. lighttpd, joka palauttaa 417 odotus epäonnistunut.
aiheuttaen viivästystä,Kun asiakas lähettää ensimmäisen Expect:100-continue-viestin, sen täytyy odottaa palvelimen vastausta ennen kuin lähettää pyyntörungon。
Jos olet varma, ettei toisen osapuolen palvelin hylkää yli 1024 tavun POST-pyyntöjä, voit välttää tämän menetelmän käytön ja välttää edellä mainitut kaksi sivuvaikutusta, ja ratkaisu on artikkelin alussa mainittu.
Noin 100 jatkaa
Tämän tarkoituksena on:
Se antaa asiakkaalle mahdollisuuden arvioida, onko palvelin valmis vastaanottamaan pyyntötiedot ennen lähettämistä, ja jos palvelin on valmis vastaanottamaan ne, asiakas itse asiassa lähettää tiedot.
Asiakkaan käyttäytyminen:
Asiakas, joka lähettää 100 jatkoa, ei saisi odottaa ikuisesti vastausta palvelimelta, ja tietyn aikakatkaisun jälkeen asiakkaan tulisi lähettää entiteetti suoraan.
Palvelinpuolen käyttäytyminen:
Jos palvelin saa 100 jatkamispyynnön, se vastaa 100 jatka tai lähettää virhekoodin. Palvelin ei voi koskaan lähettää 100 jatkoa asiakkaalle, joka ei lähetä 100 jatkoa. Mutta jotkut palvelimet tekevät niin. IIS 5 lähettää virheellisesti 100-jatkovastauksen
Jos palvelin vastaanottaa asiakkaan rungon ennen 100 jatkamisen vastausta, se tarkoittaa, että asiakas on päättänyt alkaa lähettää dataa, joten palvelin ei voi enää lähettää 100 jatkoa asiakkaalle. .NET Expect Off Expect -asetuskoodi on seuraava:
RestSharp on rakennettu seuraavasti:
|