ਅੱਪਲੋਡ ਨੂੰ ਟੁਕੜਿਆਂ ਵਿੱਚ ਪੜ੍ਹਨ ਲਈ chunked HTTP ਦੀ ਲੋੜ ਨਹੀਂ

ਨਹੀਂ। ਕਲਾਇੰਟ ਵੱਡੀ ਫ਼ਾਈਲ ਨੂੰ ਛੋਟੇ ਬਫ਼ਰਾਂ ਵਿੱਚ ਪੜ੍ਹ ਕੇ ਜਾਣੇ-ਪਛਾਣੇ Content-Length ਨਾਲ ਭੇਜ ਸਕਦਾ ਹੈ। ਸੀਮਤ ਪੜ੍ਹਤਾਂ ਮੈਮੋਰੀ ਦੀ ਵਰਤੋਂ ਨੂੰ ਕਾਬੂ ਕਰਦੀਆਂ ਹਨ; HTTP ਫ਼ਰੇਮਿੰਗ ਪ੍ਰਾਪਤਕਰਤਾ ਨੂੰ ਦੱਸਦੀ ਹੈ ਕਿ ਬੇਨਤੀ ਦਾ ਬਾਡੀ ਕਿੱਥੇ ਖ਼ਤਮ ਹੁੰਦਾ ਹੈ।

HTTP ਲਾਇਬ੍ਰੇਰੀ ਜਿਸ ਦੀ ਬਾਈਟ-ਲੰਬਾਈ ਜਾਣਦੀ ਹੈ ਅਜਿਹੀ ਸਥਿਰ ਫ਼ਾਈਲ, ਅਣਜਾਣ ਮਾਤਰਾ ਵਿੱਚ ਡੇਟਾ ਪੈਦਾ ਕਰਨ ਵਾਲੇ ਜਨਰੇਟਰ ਤੋਂ ਵੱਖਰੀ ਹੁੰਦੀ ਹੈ। ਦੋਵਾਂ ਸਰੋਤਾਂ ਲਈ ਲਾਇਬ੍ਰੇਰੀ ਵੱਲੋਂ ਸਮਰਥਿਤ ਬਾਡੀ ਇੰਟਰਫ਼ੇਸ ਵਰਤੋ। ਸਿਰਫ਼ ਲੰਬਾਈ ਦੇਣ ਲਈ ਪੂਰੀ ਫ਼ਾਈਲ ਨੂੰ ਸਟਰਿੰਗ ਵਿੱਚ ਜੋੜਨ ਦੀ ਲੋੜ ਨਹੀਂ।

HTTP/1.1 ਲਈ, ਪ੍ਰੋਟੋਕੋਲ ਦੇ ਨਿਯਮਾਂ ਅਨੁਸਾਰ ਅਸਲ ਵਿੱਚ ਭੇਜੀ ਗਈ ਫ਼ਰੇਮਿੰਗ ਦੀ ਜਾਂਚ ਕਰੋ: Content-Length ਜਾਂ chunked ਟ੍ਰਾਂਸਫ਼ਰ ਕੋਡਿੰਗ। Chunked ਕੋਡਿੰਗ ਫ਼ਾਈਲ ਦੀ ਸਮੱਗਰੀ ਤੋਂ ਬਾਹਰ ਆਕਾਰ ਦੇ ਨਿਸ਼ਾਨ ਜੋੜਦੀ ਹੈ। ਵਿਰੋਧਾਭਾਸੀ ਫ਼ਰੇਮਿੰਗ ਖੇਤਰ ਨਾ ਮਿਲਾਓ ਅਤੇ ਪ੍ਰੌਕਸੀ ਨੂੰ ਅੱਪਲੋਡ ਸਵੀਕਾਰ ਕਰਨ ਲਈ ਮਨਾਉਣ ਵਾਸਤੇ ਲੰਬਾਈ ਦਾ ਅੰਦਾਜ਼ਾ ਨਾ ਲਾਓ।

ਜੇ ਪ੍ਰੌਕਸੀ ਰਾਹੀਂ ਅੱਪਲੋਡ ਫੇਲ੍ਹ ਹੋਵੇ, ਤਾਂ HTTP ਵਰਜਨ, ਬਾਡੀ ਦਾ ਸਰੋਤ ਅਤੇ ਪਹਿਲਾ ਇਨਕਾਰ ਦਰਜ ਕਰੋ। 411 ਜਵਾਬ ਬਾਡੀ ਦੇ ਵਿਚਕਾਰ ਬੰਦ ਹੋਣ ਵਾਲੇ ਕਨੈਕਸ਼ਨ ਨਾਲੋਂ ਵੱਖਰੀ ਪੜਤਾਲ ਦਾ ਸੰਕੇਤ ਦਿੰਦਾ ਹੈ। ਜੇ ਇਸ ਦੀ ਥਾਂ ਪ੍ਰਮਾਣੀਕਰਨ ਦੇ ਦੁਬਾਰਾ ਯਤਨ ਫੇਲ੍ਹ ਹੋਣ, ਤਾਂ ਵੇਖੋ ਕੀ ਅੱਪਲੋਡ ਦਾ ਬਾਡੀ ਦੁਬਾਰਾ ਚਲਾਇਆ ਜਾ ਸਕਦਾ ਹੈ। ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਰੀਡ-ਬਫ਼ਰ ਦਾ ਆਕਾਰ ਬਦਲਣ ਨਾਲ ਬੇਨਤੀ ਦੀ ਫ਼ਰੇਮਿੰਗ ਪਹਿਲਾਂ ਵਾਂਗ ਹੀ ਰਹਿ ਸਕਦੀ ਹੈ।

ਉਸ ਨਿਰੀਖਣ ਲਈ ਰਸਤਾ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਸਾਫ਼-ਪਾਠ ਫ਼ਾਰਵਰਡਿੰਗ ਅੱਪਲੋਡ ਦੀ HTTP ਫ਼ਰੇਮਿੰਗ ਨੂੰ ਪ੍ਰੌਕਸੀ ਸਾਹਮਣੇ ਖੋਲ੍ਹਦੀ ਹੈ; ਆਮ ਐਂਡ-ਟੂ-ਐਂਡ HTTPS ਇਸਨੂੰ ਸੁਰੰਗ ਅੰਦਰ ਰੱਖਦੀ ਹੈ। HTTP/2 ਆਪਣੀ ਫ਼ਰੇਮਿੰਗ ਵਰਤਦਾ ਹੈ। ਇਸ ਲਈ ਇਤਿਹਾਸਕ Squid ਸੀਮਾਵਾਂ ਕੁਝ ਪੁਰਾਣੀਆਂ ਅਸਫਲਤਾਵਾਂ ਦੀ ਵਿਆਖਿਆ ਕਰਦੀਆਂ ਹਨ, ਇਹ ਨਿਯਮ ਨਹੀਂ ਕਿ ਅੱਜ ਦੀ ਹਰ ਪ੍ਰੌਕਸੀ ਸਟ੍ਰੀਮ ਕੀਤੇ ਅੱਪਲੋਡ ਨੂੰ ਇਨਕਾਰ ਕਰਦੀ ਹੈ।