பதிவேற்றத்தைத் துண்டுகளாகப் படிப்பதற்கு Chunked HTTP தேவையில்லை

இல்லை. ஒரு client பெரிய கோப்பைச் சிறிய buffers-ல் படித்து, தெரிந்த Content-Length உடன் அனுப்பலாம். எல்லைக்குட்பட்ட வாசிப்புகள் நினைவகப் பயன்பாட்டைக் கட்டுப்படுத்துகின்றன; HTTP framing பெறுநருக்கு request body எங்கு முடிகிறது என்பதைச் சொல்கிறது.

HTTP library-க்கு byte நீளம் தெரிந்த நிலையான கோப்பு, தெரியாத அளவு தரவை உருவாக்கும் generator-ல் இருந்து வேறுபடுகிறது. இரு மூலங்களுக்கும் library ஆதரிக்கும் body interface-ஐப் பயன்படுத்தவும். நீளத்தை வழங்க மட்டும் முழுக் கோப்பையும் ஒரு string ஆக இணைக்க வேண்டியதில்லை.

HTTP/1.1-க்கு, உண்மையில் அனுப்பப்பட்ட framing-ஐப் பாருங்கள்: protocol விதிகளின்படி Content-Length அல்லது chunked transfer coding. Chunked coding கோப்பு உள்ளடக்கத்திற்கு வெளியே அளவுக் குறியீடுகளைச் சேர்க்கிறது. முரணான framing புலங்களை இணைக்க வேண்டாம்; proxy ஏற்கும் என நம்பவைக்க நீளத்தை ஊகிக்க வேண்டாம்.

proxy வழியாக பதிவேற்றம் தோல்வியடைந்தால், HTTP பதிப்பு, body மூலம், முதல் நிராகரிப்பு ஆகியவற்றைப் பதிவு செய்யுங்கள். 411 பதில், body-யின் நடுவில் மூடப்படும் இணைப்பில் இருந்து வேறுபட்ட புலனாய்வைக் குறிக்கிறது. அதற்குப் பதிலாக authentication மறுமுயற்சிகள் தோல்வியடைந்தால், பதிவேற்ற body-ஐ மீண்டும் இயக்க முடியுமா என்பதைச் சரிபார்க்கவும். பயன்பாட்டின் read-buffer அளவை மாற்றுவது request framing-ஐ அப்படியே விட்டுவிடக்கூடும்.

அந்த அவதானிப்புக்கு பாதை முக்கியம். Plaintext forwarding பதிவேற்றத்தின் HTTP framing-ஐ proxy-க்கு வெளிப்படுத்துகிறது; சாதாரண end-to-end HTTPS அதை ஒரு tunnel-க்குள் வைக்கிறது. HTTP/2 அதன் சொந்த framing-ஐப் பயன்படுத்துகிறது. எனவே வரலாற்று Squid வரம்புகள் சில பழைய தோல்விகளை விளக்குகின்றன; இன்றைய ஒவ்வொரு proxy-யும் streamed பதிவேற்றங்களை நிராகரிக்கும் என்ற விதியை அல்ல.