అప్‌లోడ్‌ను ముక్కలుగా చదవడానికి Chunked HTTP అవసరం లేదు

కాదు. క్లయింట్ పెద్ద ఫైల్‌ను చిన్న బఫర్‌లలో చదివి, తెలిసిన Content-Length తో పంపవచ్చు. పరిమిత రీడ్‌లు మెమరీ వినియోగాన్ని నియంత్రిస్తాయి; HTTP ఫ్రేమింగ్ అభ్యర్థన బాడీ ఎక్కడ ముగుస్తుందో గ్రహీతకు చెబుతుంది.

HTTP లైబ్రరీకి బైట్ పొడవు తెలిసిన స్థిరమైన ఫైల్, తెలియని మొత్తంలో డేటాను ఉత్పత్తి చేసే జెనరేటర్ కంటే భిన్నం. రెండు మూలాలకూ లైబ్రరీ మద్దతిచ్చే బాడీ ఇంటర్‌ఫేస్‌ను ఉపయోగించండి. పొడవు ఇవ్వడానికి మాత్రమే మొత్తం ఫైల్‌ను స్ట్రింగ్‌గా కూర్చాల్సిన అవసరం లేదు.

HTTP/1.1 కోసం, వాస్తవంగా పంపిన ఫ్రేమింగ్‌ను పరిశీలించండి: ప్రోటోకాల్ నియమాల ప్రకారం Content-Length లేదా chunked transfer coding. Chunked కోడింగ్ ఫైల్ కంటెంట్ వెలుపల సైజు గుర్తులను జోడిస్తుంది. విరుద్ధమైన ఫ్రేమింగ్ ఫీల్డ్‌లను కలపవద్దు; proxy అంగీకరించేలా చేయడానికి పొడవును ఊహించవద్దు.

proxy ద్వారా అప్‌లోడ్ విఫలమైతే, HTTP వెర్షన్, బాడీ మూలం మరియు మొదటి తిరస్కరణను నమోదు చేయండి. 411 ప్రతిస్పందన బాడీ మధ్యలో మూసుకుపోయే కనెక్షన్ కంటే భిన్నమైన దర్యాప్తును సూచిస్తుంది. బదులుగా authentication రీట్రైలు విఫలమైతే, అప్‌లోడ్ బాడీని మళ్లీ ప్లే చేయగలరా చూడండి. అప్లికేషన్ రీడ్-బఫర్ పరిమాణాన్ని మార్చడం అభ్యర్థన ఫ్రేమింగ్‌ను యథాతథంగా వదిలేయవచ్చు.

ఆ పరిశీలనకు మార్గం ముఖ్యం. Plaintext ఫార్వర్డింగ్ అప్‌లోడ్ HTTP ఫ్రేమింగ్‌ను proxyకు బహిర్గతం చేస్తుంది; సాధారణ end-to-end HTTPS దానిని టన్నెల్ లోపల ఉంచుతుంది. HTTP/2 తన సొంత ఫ్రేమింగ్‌ను ఉపయోగిస్తుంది. అందువల్ల చారిత్రక Squid పరిమితులు కొన్ని పాత వైఫల్యాలను వివరిస్తాయి, ప్రస్తుత proxy ప్రతిదీ స్ట్రీమ్ చేసిన అప్‌లోడ్‌లను తిరస్కరిస్తుందనే నియమాన్ని కాదు.