ਫਾਰਵਰਡ ਪ੍ਰੌਕਸੀ ਬੇਨਤੀ ਲਾਈਨ ਅਤੇ ਹੈਡਰ ਪੜ੍ਹਦੀ ਹੈ, ਉਹਨਾਂ ਨੂੰ ਅੱਗੇ ਭੇਜਦੀ ਹੈ, ਫਿਰ select ਵਿੱਚ POST ਬਾਡੀ ਦੀ ਉਡੀਕ ਕਰਦੀ ਹੈ। ਕਲਾਇੰਟ ਇਸਨੂੰ ਪਹਿਲਾਂ ਹੀ ਭੇਜ ਚੁੱਕਾ ਹੈ। ਦੋਵੇਂ ਪਾਸੇ ਇੱਕ-ਦੂਜੇ ਦੀ ਉਡੀਕ ਕਰਦੇ ਦਿਸਦੇ ਹਨ।

Python ਦੇ BaseHTTPRequestHandler ਨਾਲ, ਹੈਡਰ ਪੜ੍ਹਨਾ rfile ਰਾਹੀਂ ਹੁੰਦਾ ਹੈ, ਜੋ ਇੱਕ ਬਫਰ ਕੀਤਾ ਇਨਪੁਟ ਸਟ੍ਰੀਮ ਹੈ। ਉਹ ਸਟ੍ਰੀਮ ਅੱਗੇ ਪੜ੍ਹ ਸਕਦੀ ਹੈ ਅਤੇ ਬਾਡੀ ਦੇ ਬਾਈਟ ਰੱਖ ਸਕਦੀ ਹੈ। ਹੇਠਲੇ socket ਉੱਤੇ ਉਡੀਕ ਕਰਨਾ ਸਿਰਫ਼ ਇਹ ਪੁੱਛਦਾ ਹੈ ਕਿ ਇਸਦਾ ਫਾਈਲ ਡਿਸਕ੍ਰਿਪਟਰ ਤਿਆਰ ਹੈ ਜਾਂ ਨਹੀਂ; ਇਹ ਨਹੀਂ ਪੁੱਛਦਾ ਕਿ Python ਸਟ੍ਰੀਮ ਵਿੱਚ ਪਹਿਲਾਂ ਹੀ ਵਰਤੋਂਯੋਗ ਡੇਟਾ ਹੈ ਜਾਂ ਨਹੀਂ।

ਹੈਡਰ ਪੜ੍ਹਨ ਵਾਲੇ ਬਫਰ ਦੀ ਪੈਰਵੀ ਕਰੋ

ਬਾਡੀ ਵੀ self.rfile ਰਾਹੀਂ ਪੜ੍ਹੋ। ਬਫਰ ਕੀਤੀ ਸਟ੍ਰੀਮ ਨਾਲ ਹੈਡਰ ਪਾਰਸ ਕਰਨ ਤੋਂ ਬਾਅਦ self.connection.recv ਉੱਤੇ ਨਾ ਜਾਓ। ਨਹੀਂ ਤਾਂ ਕੋਡ ਉਸ ਸਟ੍ਰੀਮ ਵੱਲੋਂ ਰੱਖੇ ਬਾਈਟ ਛੱਡ ਕੇ ਉਸ ਡੇਟਾ ਦੀ ਉਡੀਕ ਕਰ ਸਕਦਾ ਹੈ ਜੋ ਕਦੇ ਦੁਬਾਰਾ ਨਹੀਂ ਭੇਜਿਆ ਜਾਵੇਗਾ।

rfile ਨੂੰ ਆਪ ਹੀ select ਨੂੰ ਦੇਣ ਨਾਲ select ਇਸਦਾ Python ਬਫਰ ਨਹੀਂ ਵੇਖਦਾ। ਤਿਆਰੀ API ਵਸਤੂ ਦੇ ਫਾਈਲ ਡਿਸਕ੍ਰਿਪਟਰ ਰਾਹੀਂ ਕੰਮ ਕਰਦੀ ਹੈ।

ਇੱਕ ਵੈਧ Content-Length ਵਾਲੀ ਅਤੇ Transfer-Encoding ਤੋਂ ਬਿਨਾਂ ਬੇਨਤੀ ਲਈ, ਘੋਸ਼ਿਤ ਬਾਈਟ ਗਿਣਤੀ ਬਿਲਕੁਲ ਉੱਨੀ ਹੀ ਵਰਤੋ, ਇਨਪੁਟ ਦੇ ਸਮੇਂ ਤੋਂ ਪਹਿਲਾਂ ਖ਼ਤਮ ਹੋਣ ਅਤੇ ਆਪਣੀਆਂ ਆਕਾਰ ਤੇ ਸਮਾਂ ਸੀਮਾਵਾਂ ਨੂੰ ਸੰਭਾਲੋ। EOF ਤੱਕ ਨਾ ਪੜ੍ਹੋ: ਸਥਾਈ ਕਨੈਕਸ਼ਨ ਵਰਤਣ ਵਾਲਾ ਕਲਾਇੰਟ ਬੇਨਤੀ ਪੂਰੀ ਹੋਣ ਤੋਂ ਬਾਅਦ ਵੀ ਕਨੈਕਸ਼ਨ ਖੁੱਲ੍ਹਾ ਰੱਖ ਸਕਦਾ ਹੈ।

ਫਰੇਮਿੰਗ ਨੂੰ ਪ੍ਰੌਕਸੀ ਦਾ ਸਪਸ਼ਟ ਹਿੱਸਾ ਬਣਾਓ

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

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

ਇਹ ਨਿਦਾਨ ਇਸ ਗੱਲ ਬਾਰੇ ਹੈ ਕਿ ਆਉਣ ਵਾਲੇ ਬਾਈਟ ਕਿੱਥੇ ਰੱਖੇ ਜਾਂਦੇ ਹਨ। ਪ੍ਰੌਕਸੀ ਸਹੀ ਬਾਡੀ ਵਰਤਣ ਤੋਂ ਬਾਅਦ ਵੀ ਉਹ ਬਾਡੀ ਸੰਗਤ HTTP ਫਰੇਮਿੰਗ ਨਾਲ ਅੱਗੇ ਭੇਜਣੀ ਪੈਂਦੀ ਹੈ। ਮਿਆਰੀ http.server handler ਸਮਝਣ ਲਈ ਲਾਹੇਵੰਦ ਥਾਂ ਹੈ, ਪਰ ਇਹ ਉਤਪਾਦਨ ਫਾਰਵਰਡ-ਪ੍ਰੌਕਸੀ ਲਾਗੂਕਰਨ ਨਹੀਂ ਹੈ।

ਸੰਬੰਧਿਤ ਲੇਖ