HTTP augšupielādes pauzes un Expect: 100-continue
Atpazīstiet Expect: 100-continue apmaiņu un atšķiriet tās īso lēmuma punktu no augšupielādes, kas iestrēgusi datu pārsūtīšanas laikā.
Savienojums tiek atvērts. Pieprasījuma galvenes aiziet. Šķiet, ka fails nevirzās. Viens skaidrojums ir tāds, ka klients gaida atbildi uz Expect: 100-continue pirms sava satura nosūtīšanas.
Mehānisms ļauj saņēmējam noraidīt pieprasījumu pēc tā galvenēm pirms potenciāli lielas augšupielādes nosūtīšanas. Parastā veiksmīgā secība ir:
request headers → 100 Continue → request body → final response100 ir informatīvs: tas ļauj klientam turpināt, bet nenozīmē, ka fails ir saglabāts vai lietojumprogrammas darbība ir izdevusies. Git push, kas atgriež HTTP 417, ir viens konkrēts gaidīšanas neizdošanās gadījums.
Noskaidrojiet, kādu atbildi klients saņēma
| Novērojums | Ko izmeklēt |
|---|---|
| 100 Continue | Klients var turpināt ar saturu |
| Galīgais noraidījums pirms satura | Darbība tika atteikta galveņu posmā |
| Nav gaidītās starpatbildes | Klienta gaidīšanas politika un apstrāde šajā ceļā |
curl piedāvā atsevišķu expect-continue gaidīšanas iestatījumu. Ja šī libcurl gaidīšana beidzas bez gaidītās atbildes, tas saturu tomēr nosūta; beigšanās pati par sevi nav visas pārsūtīšanas neizdošanās. Iestatījums ir atsevišķs no visa pārsūtīšanai atļautā laika. Palielinot pēdējo, tā pati sākotnējā pauze var palikt neizskaidrota.
Noskaidrojiet arī to, kurā HTTP sarunā tiek pārsūtīts Expect. Parastā CONNECT uz HTTPS galamērķi gadījumā vietnes augšupielādes apmaiņa notiek TLS iekšpusē; starpniekserveris vienkārši neaplūko iekšējo gaidīšanas galveni. Pārtveršanas vai atklāta teksta pārsūtīšanas ceļš ir citāds.
Gaidīšanas noņemšana var būt apzināta saderības izvēle, taču tas nozīmē, ka klients var sākt sūtīt lielu saturu, pirms uzzina par agrīnu noraidījumu. Salīdziniet šo uzvedību ar faktiskajām prasībām. Neaprakstiet vēsturisku risinājumu vecam starpniekserverim kā universālu norādījumu noņemt galveni no katras augšupielādes.