ਡੀਬੱਗਿੰਗ ਪ੍ਰੌਕਸੀ ਨਾਲ ਅਸਫਲਤਾ ਦੇ ਕੇਸ ਤਿਆਰ ਕਰਨਾ

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

“ਬੇਨਤੀ ਅਸਫਲ ਹੋਈ” ਬਹੁਤ ਵਿਆਪਕ ਜਾਂਚ ਕੇਸ ਹੈ। ਇੱਕ ਵੈਧ HTTP ਗਲਤੀ ਜਵਾਬ, ਕਦੇ ਨਾ ਆਉਣ ਵਾਲਾ ਜਵਾਬ ਅਤੇ ਡਾਊਨਲੋਡ ਵਿਚਕਾਰ ਟੁੱਟਿਆ ਕਨੈਕਸ਼ਨ ਐਪਲੀਕੇਸ਼ਨ ਤੋਂ ਵੱਖਰੀਆਂ ਚੀਜ਼ਾਂ ਮੰਗਦੇ ਹਨ।

ਸਹੀ ਪਰਤ 'ਤੇ ਦਖਲ ਵਰਤੋ

Charles ਅਜਿਹੇ ਬ੍ਰੇਕਪੌਇੰਟ ਦਿੰਦਾ ਹੈ ਜੋ ਬੇਨਤੀ ਜਾਂ ਜਵਾਬ ਨੂੰ ਅੱਗੇ ਭੇਜਣ ਤੋਂ ਪਹਿਲਾਂ ਰੋਕਦੇ ਹਨ। ਰੋਕੇ ਗਏ ਸੁਨੇਹੇ ਦੀ ਜਾਂਚ ਅਤੇ ਸੋਧ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ, ਲੰਘਣ ਦਿੱਤਾ ਜਾ ਸਕਦਾ ਹੈ ਜਾਂ ਰੱਦ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਇਸ ਦਾ Rewrite ਟੂਲ ਮਿਲਦੇ ਹੈਡਰਾਂ, URLਾਂ ਜਾਂ ਬਾਡੀਆਂ 'ਤੇ ਦੁਹਰਾਉਣ ਯੋਗ ਬਦਲਾਅ ਲਾਗੂ ਕਰਦਾ ਹੈ। ਥ੍ਰੌਟਲਿੰਗ ਬੈਂਡਵਿਡਥ ਅਤੇ ਵਾਧੂ ਲੇਟੈਂਸੀ ਨਿਯੰਤਰਿਤ ਕਰਦੀ ਹੈ।

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

ਹਰ ਕੇਸ ਨੂੰ ਸਮਝਣਯੋਗ ਰੱਖੋ

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

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

HTTPS ਸਮੱਗਰੀ ਦੀ ਜਾਂਚ ਜਾਂ ਸੋਧ ਲਈ ਕਲਾਇੰਟ ਨੂੰ ਡੀਬੱਗਿੰਗ ਪ੍ਰੌਕਸੀ ਦੇ TLS ਨਿਰੀਖਣ ਸੈਟਅਪ ਵਿੱਚ ਹਿੱਸਾ ਲੈਣਾ ਪੈਂਦਾ ਹੈ। ਸਿਰਫ਼ CONNECT ਲਿਜਾਣ ਵਾਲੀ ਪ੍ਰੌਕਸੀ ਇਨਕ੍ਰਿਪਟਿਡ ਐਪਲੀਕੇਸ਼ਨ ਬਾਈਟਾਂ ਦੇਖਦੀ ਹੈ। ਵੱਖਰਾ ਜਾਂਚ ਸੰਰਚਨਾ ਵਰਤੋ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਇਸ ਦੀ ਰੂਟਿੰਗ ਅਤੇ ਭਰੋਸਾ ਸੈਟਅਪ ਬਹਾਲ ਕਰੋ, ਤਾਂ ਜੋ ਬਾਅਦ ਦੇ ਨਿਰੀਖਣ ਸਧਾਰਨ ਕਲਾਇੰਟ ਦਾ ਵਰਣਨ ਕਰਨ।