HTTP CONNECT ਜਵਾਬ ਤੋਂ ਬਾਅਦ ਬਫਰ ਕੀਤਾ ਡੇਟਾ ਸੰਭਾਲੋ

ਇੱਕ ਛੋਟਾ ਪ੍ਰੌਕਸੀ ਰੈਪਰ HTTPS ਲਈ ਕੰਮ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਫਿਰ ਅਜਿਹੇ ਪ੍ਰੋਟੋਕੋਲ ਲਈ ਦੁਬਾਰਾ ਵਰਤੋਂ ’ਤੇ ਅਟਕ ਸਕਦਾ ਹੈ ਜਿਸਦਾ ਸਰਵਰ ਪਹਿਲਾਂ ਬੋਲਦਾ ਹੈ। ਸ਼ੱਕੀ ਲਾਈਨ ਆਮ ਤੌਰ ’ਤੇ ਉਹੀ ਹੁੰਦੀ ਹੈ ਜੋ ਪ੍ਰਾਪਤੀ ਬਫਰ ਦੇ \r\n\r\n ਨਾਲ ਖ਼ਤਮ ਹੋਣ ਦੀ ਉਡੀਕ ਕਰਦੀ ਹੈ।

TCP ਕਲਾਇੰਟ ਨੂੰ ਸਟ੍ਰੀਮ ਦਿੰਦਾ ਹੈ। ਇੱਕ ਪ੍ਰਾਪਤੀ ਕਾਲ ਅੱਧੀ HTTP ਸਟੇਟਸ ਲਾਈਨ, ਪੂਰਾ CONNECT ਜਵਾਬ, ਜਾਂ ਉਹ ਜਵਾਬ ਤੁਰੰਤ ਟਨਲ ਡੇਟਾ ਸਮੇਤ ਵਾਪਸ ਕਰ ਸਕਦੀ ਹੈ। ਕੋਈ ਭਰੋਸਾ ਨਹੀਂ ਕਿ ਪੜ੍ਹਤ ਹੈਡਰਾਂ ਦੇ ਅੰਤ ’ਤੇ ਰੁਕੇਗੀ।

ਬਫਰ ਦੇ ਅੰਦਰ ਸੀਮਾ ਲੱਭੋ

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

ਅੰਤਿਮ ਸਫਲ 2xx ਜਵਾਬ ਉਹਨਾਂ ਹੈਡਰਾਂ ਤੋਂ ਤੁਰੰਤ ਬਾਅਦ ਕਨੈਕਸ਼ਨ ਨੂੰ ਟਨਲ ਮੋਡ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ। ਇਸ ਤੋਂ ਬਾਅਦ ਆਉਣ ਵਾਲੇ ਬਾਈਟ ਪਹਿਲਾਂ ਹੀ ਟਨਲ ਬਾਈਟ ਹਨ। ਇਹਨਾਂ ਨੂੰ ਸੁੱਟੋ ਨਾ, CONNECT ਜਵਾਬ ਬਾਡੀ ਦੀ ਉਡੀਕ ਨਾ ਕਰੋ, ਅਤੇ Content-Length ਖੇਤਰ ਨੂੰ ਨਵੇਂ ਪ੍ਰੋਟੋਕੋਲ ਦਾ ਹਿੱਸਾ ਵਰਤਣ ਦੀ ਇਜਾਜ਼ਤ ਨਾ ਸਮਝੋ। ਜਾਣਕਾਰੀ ਵਾਲੇ ਜਵਾਬ, ਜੇ ਹੋਣ, ਉਸ ਅੰਤਿਮ ਜਵਾਬ ਤੋਂ ਪਹਿਲਾਂ ਸੰਭਾਲੇ ਜਾਣੇ ਚਾਹੀਦੇ ਹਨ।

ਰੈਪਰ ਨੂੰ ਆਪਣੇ ਬਚੇ ਹੋਏ ਹਿੱਸੇ ਅੱਗੇ ਭੇਜਣੇ ਚਾਹੀਦੇ ਹਨ

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

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

ਇਹ ਖ਼ਾਸਕਰ ਤਦ ਮਹੱਤਵਪੂਰਨ ਹੈ ਜਦੋਂ HTTP ਪ੍ਰੌਕਸੀ ਰਾਹੀਂ FTP ਜਾਂ SSH ਕਲਾਇੰਟ ਨੂੰ ਅਨੁਕੂਲ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਪ੍ਰੌਕਸੀ ਨੂੰ ਬੇਨਤੀ ਕੀਤੀ ਮੰਜ਼ਿਲ ਪੋਰਟ ਦੀ ਵੀ ਇਜਾਜ਼ਤ ਦੇਣੀ ਪੈਂਦੀ ਹੈ, ਅਤੇ FTP ਨੂੰ ਵਾਧੂ ਡੇਟਾ ਕਨੈਕਸ਼ਨ ਲੋੜੀਂਦੇ ਹੋ ਸਕਦੇ ਹਨ। ਸਹੀ ਹੈਡਰ ਪਾਰਸਿੰਗ ਸਟ੍ਰੀਮ ਹੈਂਡਓਫ਼ ਹੱਲ ਕਰਦੀ ਹੈ; ਇਹ CONNECT ਇਜਾਜ਼ਤ ਨਹੀਂ ਦੇ ਸਕਦੀ ਅਤੇ ਨਾ ਹੀ FTP ਦਾ ਦੂਜਾ ਚੈਨਲ ਦੇ ਸਕਦੀ ਹੈ।