HTTP అప్‌లోడ్ విరామాలు మరియు Expect: 100-continue
Expect: 100-continue మార్పిడిని గుర్తించి, దాని చిన్న నిర్ణయ బిందువును డేటా బదిలీ సమయంలో నిలిచిపోయిన అప్‌లోడ్ నుండి వేరు చేయండి.
కనెక్షన్ తెరుచుకుంటుంది. అభ్యర్థన హెడర్లు బయలుదేరుతాయి. ఫైల్ కదలనట్లు కనిపిస్తుంది. ఒక వివరణ ఏమిటంటే, క్లయింట్ తన బాడీని పంపే ముందు Expect: 100-continue కి ప్రతిస్పందన కోసం వేచి ఉంది.
ఈ యంత్రాంగం గ్రహీతను, సంభావ్యంగా పెద్ద అప్‌లోడ్ పంపబడకముందే దాని హెడర్ల ఆధారంగా అభ్యర్థనను తిరస్కరించడానికి అనుమతిస్తుంది. సాధారణ విజయవంత క్రమం:
request headers → 100 Continue → request body → final response100 సమాచారాత్మకం: ఇది క్లయింట్ కొనసాగడానికి అనుమతిస్తుంది, కానీ ఫైల్ నిల్వ చేయబడిందని లేదా అప్లికేషన్ చర్య విజయవంతమైందని అర్థం కాదు. HTTP 417 తిరిగి ఇచ్చే Git push అలాంటి ఒక నిర్దిష్ట ఆశ-వైఫల్య సందర్భం.
క్లయింట్ ఏ ప్రతిస్పందన పొందిందో కనుగొనండి
| పరిశీలన | ఏమి పరిశోధించాలి |
|---|---|
| 100 Continue | క్లయింట్ బాడీతో కొనసాగవచ్చు |
| బాడీకి ముందు తుది తిరస్కరణ | చర్య హెడర్ దశలో తిరస్కరించబడింది |
| ఆశించిన మధ్యంతర ప్రతిస్పందన లేదు | క్లయింట్ యొక్క నిరీక్షణ విధానం మరియు ఆ మార్గంలో నిర్వహణ |
curl లో expect-continue నిరీక్షణకు ప్రత్యేక సెట్టింగ్ ఉంది. ఆ libcurl నిరీక్షణ ఆశించిన ప్రతిస్పందన లేకుండా గడువు ముగిస్తే, అది బాడీని ఏమైనా పంపుతుంది; గడువు ముగియడం స్వయంచాలకంగా పూర్తి బదిలీ వైఫల్యం కాదు. ఈ సెట్టింగ్ పూర్తి బదిలీకి అనుమతించిన సమయం నుండి వేరుగా ఉంటుంది. తరువాతది పెంచడం అదే ప్రారంభ విరామాన్ని వివరణ లేకుండా వదిలేయవచ్చు.
ఏ HTTP సంభాషణ Expect ను మోసుకెళ్తుందో కూడా గుర్తించండి. HTTPS గమ్యస్థానానికి సాధారణ CONNECT తో, వెబ్‌సైట్ అప్‌లోడ్ మార్పిడి TLS లోపల ఉంటుంది; ఫార్వర్డ్ ప్రాక్సీ దాని లోపలి ఆశ హెడర్‌ను సరళంగా పరిశీలించదు. అంతరాయం లేదా సాదా పాఠ్య ఫార్వర్డింగ్ మార్గం భిన్నం.
ఆశను తొలగించడం ఉద్దేశపూర్వక సామరస్య ఎంపిక కావచ్చు, కానీ దాని అర్థం క్లయింట్ ముందస్తు తిరస్కరణను తెలుసుకోకముందే పెద్ద బాడీని పంపడం ప్రారంభించవచ్చు. ఆ ప్రవర్తనను వాస్తవ అవసరంతో పోల్చండి. పాత ప్రాక్సీ కోసం చారిత్రక పరిష్కారాన్ని ప్రతి అప్‌లోడ్ నుండి హెడర్‌ను తొలగించే సార్వత్రిక సూచనగా వివరించవద్దు.