ਜਦੋਂ ਡਾਊਨਲੋਡ ਕੀਤੀ ਫ਼ਾਈਲ HTTP ਸਥਿਤੀ ਲਾਈਨ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ

ਜੇ PDF ਜਾਂ ਸਪ੍ਰੈਡਸ਼ੀਟ ਵਰਗੀ ਦਿਖਣ ਵਾਲੀ ਫ਼ਾਈਲ HTTP/1.1 200 OK ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਡਾਊਨਲੋਡਰ ਨੇ ਫ਼ਾਈਲ ਦੀ ਥਾਂ ਕੱਚਾ ਜਵਾਬ ਸੰਭਾਲਿਆ ਹੈ। ਇਸ ਯੋਜਨਾਬੱਧ ਜਵਾਬ ਵਿੱਚ ਸਿਰਫ਼ ਚਾਰ ਬਾਈਟ ਸਮੱਗਰੀ ਹੈ:

HTTP/1.1 200 OK
Transfer-Encoding: chunked

4
DATA
0

ਫ਼ਾਈਲ DATA ਹੈ। ਸਥਿਤੀ ਲਾਈਨ, ਹੈਡਰ, ਆਕਾਰ ਮਾਰਕਰ ਅਤੇ ਸਮਾਪਤੀ ਢਾਂਚਾ HTTP ਦੇ ਹਨ। ਹੈਡਰ ਦੀ ਲੰਬਾਈ ਵੱਖਰੀ ਹੋਣ ਕਰਕੇ ਨਿਸ਼ਚਿਤ ਬਾਈਟ ਹਟਾਉਣਾ ਸੁਰੱਖਿਅਤ ਨਹੀਂ ਹੈ। ਪਹਿਲੀ ਖਾਲੀ ਲਾਈਨ ਤੋਂ ਬਾਅਦ ਸਭ ਕੁਝ ਕਾਪੀ ਕਰਨ ਨਾਲ ਵੀ ਚੰਕ ਫਰੇਮਿੰਗ ਰਹਿ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਜਾਣਕਾਰੀ ਵਾਲੇ ਜਵਾਬ ਅੰਤਿਮ ਜਵਾਬ ਤੋਂ ਪਹਿਲਾਂ ਆ ਸਕਦੇ ਹਨ।

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

ਸਮੱਗਰੀ ਐਨਕੋਡਿੰਗ ਇੱਕ ਹੋਰ ਪਰਤ ਹੈ। ਕਲਾਇੰਟ ਦੇ ਦਸਤਾਵੇਜ਼ੀ ਵਿਵਹਾਰ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਫੈਸਲਾ ਕਰੋ ਕਿ ਤੁਹਾਨੂੰ ਡੀਕੋਡ ਕੀਤੇ ਫ਼ਾਈਲ ਬਾਈਟ ਚਾਹੀਦੇ ਹਨ ਜਾਂ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਮੰਗੀ ਕੱਚੀ ਸਮੱਗਰੀ। ਕੰਪ੍ਰੈਸ ਕੀਤੇ ਬਾਈਟ ਆਪਣੇ ਆਪ ਪ੍ਰੌਕਸੀ ਦੀ ਖਰਾਬੀ ਨਹੀਂ ਹੁੰਦੇ।

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

HTTPS ਲਈ CONNECT ਜਵਾਬ ਹਟਾਉਣ ਤੋਂ ਵੱਧ ਲੋੜ ਹੁੰਦੀ ਹੈ: ਸੁਰੰਗ ਸਫਲਤਾਪੂਰਵਕ ਸਥਾਪਤ ਹੋਣ ਤੋਂ ਬਾਅਦ, ਮੰਜ਼ਿਲ TLS ਸਥਾਪਤ ਕਰੋ ਅਤੇ ਫਿਰ ਅੰਦਰੂਨੀ HTTP ਜਵਾਬ ਪਾਰਸ ਕਰੋ। ਪ੍ਰੌਕਸੀ ਦੇ ਹੈਡਰਾਂ ਤੋਂ ਬਾਅਦ ਦੇ ਐਨਕ੍ਰਿਪਟਡ ਬਾਈਟ ਡਾਊਨਲੋਡ ਯੋਗ ਫ਼ਾਈਲ ਨਹੀਂ ਹਨ।

ਅਸਫਲ ਜਾਂ ਅਧੂਰੇ ਆਉਟਪੁੱਟ ਨੂੰ ਅਸਥਾਈ ਨਾਮ ਹੇਠ ਰੱਖੋ। ਸਥਾਨਾਂਤਰਣ ਅਤੇ ਫ਼ਾਈਲ ਜਾਂਚਾਂ ਸਫਲ ਹੋਣ ਤੋਂ ਬਾਅਦ ਹੀ ਇਸਨੂੰ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰੋ; ਖਾਲੀ ਨਾ ਹੋਣ ਵਾਲੀ ਫ਼ਾਈਲ ਪੂਰੀ ਡਾਊਨਲੋਡ ਸਾਬਤ ਨਹੀਂ ਕਰਦੀ।