CORS ਚੈਕਰ

CORS ਨੀਤੀ ਨੂੰ ਸਮਝਣਾ

Cross-Origin Resource Sharing (CORS) ਇੱਕ ਸੁਰੱਖਿਆ ਵਿਧੀ ਹੈ ਜੋ ਵੈੱਬ ਬ੍ਰਾਊਜ਼ਰਾਂ ਦੁਆਰਾ ਲਾਗੂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਇਹ ਨਿਯੰਤਰਿਤ ਕਰਦੀ ਹੈ ਕਿ ਇੱਕ ਵੈੱਬ ਪੇਜ 'ਤੇ ਚੱਲ ਰਿਹਾ ਸਕ੍ਰਿਪਟ ਕੋਡ ਕਿਸੇ ਦੂਜੇ ਮੂਲ (origin) ਤੋਂ ਸਰੋਤਾਂ ਦੀ ਮੰਗ ਕਿਵੇਂ ਅਤੇ ਕਦੋਂ ਕਰ ਸਕਦਾ ਹੈ। ਜਦੋਂ ਕੋਈ ਬ੍ਰਾਊਜ਼ਰ ਕਿਸੇ ਵੱਖਰੇ ਡੋਮੇਨ, ਪ੍ਰੋਟੋਕੋਲ ਜਾਂ ਪੋਰਟ 'ਤੇ ਬੇਨਤੀ ਭੇਜਦਾ ਹੈ, ਤਾਂ ਉਹ CORS ਨਿਯਮਾਂ ਦੀ ਪਾਲਣਾ ਕਰਦਾ ਹੈ।

ਇਹ ਟੂਲ ਇਹ ਸਮਝਣ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ ਕਿ ਕੀ ਕੋਈ ਵੈੱਬ ਬ੍ਰਾਊਜ਼ਰ ਤੁਹਾਡੇ ਦੁਆਰਾ ਪ੍ਰਦਾਨ ਕੀਤੇ ਗਏ HTTP ਜਵਾਬ ਸਿਰਲੇਖਾਂ (response headers) ਅਤੇ ਬੇਨਤੀ ਦੇ ਵੇਰਵਿਆਂ ਦੇ ਅਧਾਰ 'ਤੇ ਕਿਸੇ ਖਾਸ ਕਰਾਸ-ਓਰੀਜਨ ਬੇਨਤੀ ਦੀ ਆਗਿਆ ਦੇਵੇਗਾ ਜਾਂ ਨਹੀਂ। ਇਹ ਫਰੰਟ-ਐਂਡ ਡਿਵੈਲਪਰਾਂ, ਬੈਕ-ਐਂਡ ਡਿਵੈਲਪਰਾਂ, API ਪਲੇਟਫਾਰਮ ਡਿਵੈਲਪਰਾਂ, ਅਤੇ ਓਪਰੇਸ਼ਨ ਡਿਵੈਲਪਰਾਂ ਲਈ ਲਾਭਦਾਇਕ ਹੈ ਜੋ ਇਹ ਜਾਂਚਣਾ ਚਾਹੁੰਦੇ ਹਨ ਕਿ ਕੀ ਬ੍ਰਾਊਜ਼ਰ ਕੋਡ ਕਿਸੇ ਖਾਸ ਜਵਾਬ ਨੂੰ ਪੜ੍ਹ ਸਕਦਾ ਹੈ।

CORS ਚੈਕਰ ਦੇ ਇਨਪੁਟਸ ਅਤੇ ਨਿਯਮ

ਇਸ ਟੂਲ ਦੀ ਵਰਤੋਂ ਕਰਨ ਲਈ, ਤੁਹਾਨੂੰ ਕੁਝ ਖਾਸ ਇਨਪੁਟਸ ਪ੍ਰਦਾਨ ਕਰਨੇ ਪੈਂਦੇ ਹਨ, ਜਿਨ੍ਹਾਂ ਦੀ ਅਧਿਕਤਮ ਲੰਬਾਈ ਅਤੇ ਫਾਰਮੈਟ ਨਿਯਮਾਂ ਅਨੁਸਾਰ ਜਾਂਚ ਕੀਤੀ ਜਾਂਦੀ ਹੈ:

• ਚੈੱਕ ਕਰਨ ਲਈ ਜਵਾਬ: ਤੁਸੀਂ "ਅਸਲ ਜਵਾਬ" ਜਾਂ "ਪ੍ਰੀਫਲਾਈਟ ਪ੍ਰਤੀਕ੍ਰਿਆ" ਵਿੱਚੋਂ ਇੱਕ ਦੀ ਚੋਣ ਕਰ ਸਕਦੇ ਹੋ।
• HTTP ਜਵਾਬ ਸਿਰਲੇਖ: ਇੱਥੇ HTTP ਜਵਾਬ ਸਿਰਲੇਖ ਪੇਸਟ ਕੀਤੇ ਜਾਂਦੇ ਹਨ। ਪ੍ਰੀਫਲਾਈਟ ਜਵਾਬਾਂ ਲਈ ਸਥਿਤੀ ਲਾਈਨ (status line) ਨੂੰ ਸ਼ਾਮਲ ਕਰਨਾ ਜ਼ਰੂਰੀ ਹੈ। ਇਸ ਇਨਪੁਟ ਦੀ ਅਧਿਕਤਮ ਸੀਮਾ 200,000 ਅੱਖਰ ਹੈ। ਜੇਕਰ ਇਹ ਖਾਲੀ ਹੈ, ਤਾਂ "ਜਾਂਚ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ HTTP ਜਵਾਬ ਸਿਰਲੇਖਾਂ ਨੂੰ ਚਿਪਕਾਓ।" ਗਲਤੀ ਸੁਨੇਹਾ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ। ਜੇਕਰ ਇਹ ਬਹੁਤ ਵੱਡਾ ਹੈ, ਤਾਂ "ਇਹ ਹੁੰਗਾਰਾ ਅਸਧਾਰਨ ਤੌਰ 'ਤੇ ਵੱਡਾ ਹੈ. ਇਸ ਨੂੰ ‹max› ਅੱਖਰਾਂ ਦੇ ਹੇਠਾਂ ਰੱਖੋ।" ਸੁਨੇਹਾ ਮਿਲਦਾ ਹੈ। ਗਲਤ ਲਾਈਨ ਹੋਣ 'ਤੇ "ਲਾਈਨ ‹line› ਇੱਕ ਵੈਧ HTTP ਸਿਰਲੇਖ ਜਾਂ ਸਥਿਤੀ ਲਾਈਨ ਨਹੀਂ ਹੈ।" ਅਤੇ ਗਲਤ ਸਿਰਲੇਖ ਨਾਮ ਹੋਣ 'ਤੇ "ਲਾਈਨ ‹line› ਵਿੱਚ ਇੱਕ ਅਵੈਧ HTTP ਸਿਰਲੇਖ ਨਾਮ ਹੁੰਦਾ ਹੈ।" ਵਰਗੀਆਂ ਗਲਤੀਆਂ ਦਿਖਾਈ ਦਿੰਦੀਆਂ ਹਨ।
• ਬੇਨਤੀ ਮੂਲ: ਇਹ ਬੇਨਤੀ ਭੇਜਣ ਵਾਲੇ ਸਰੋਤ ਦੀ ਸਕੀਮ, ਹੋਸਟ ਅਤੇ ਵਿਕਲਪਿਕ ਪੋਰਟ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ (ਉਦਾਹਰਨ: https://app.example.com)। ਇਹ ਕੇਵਲ ਇੱਕ ਸ਼ੁੱਧ ਮੂਲ ਜਾਂ null ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ URL ਮਾਰਗ, ਪੁੱਛਗਿੱਛ (query), ਜਾਂ ਪ੍ਰਮਾਣ ਪੱਤਰ ਸ਼ਾਮਲ ਨਹੀਂ ਹੋ ਸਕਦੇ। ਗਲਤ ਹੋਣ 'ਤੇ "ਕੇਵਲ ਇੱਕ ਸਕੀਮ, ਹੋਸਟ ਅਤੇ ਵਿਕਲਪਿਕ ਪੋਰਟ ਨਾਲ ਮੂਲ ਦਰਜ ਕਰੋ, ਜਿਵੇਂ ਕਿ https://app.example.com।" ਗਲਤੀ ਆਉਂਦੀ ਹੈ।
• ਬੇਨਤੀ ਕੀਤੀ ਵਿਧੀ: HTTP ਵਿਧੀ (ਜਿਵੇਂ GET, POST) ਦਰਜ ਕਰੋ। ਗਲਤ ਟੋਕਨ ਹੋਣ 'ਤੇ "ਇੱਕ ਵੈਧ HTTP ਵਿਧੀ ਟੋਕਨ ਦਾਖਲ ਕਰੋ।" ਅਤੇ ਬ੍ਰਾਊਜ਼ਰ ਦੁਆਰਾ ਵਰਜਿਤ ਵਿਧੀ ਹੋਣ 'ਤੇ "ਬ੍ਰਾਊਜ਼ਰ ਬੇਨਤੀਆਂ ਪ੍ਰਾਪਤ ਕਰਨ ਵਿੱਚ ‹method› ਵਿਧੀ ਦੀ ਇਜਾਜ਼ਤ ਨਹੀਂ ਦਿੰਦੇ।" ਸੁਨੇਹਾ ਮਿਲਦਾ ਹੈ।
• ਬੇਨਤੀ ਕੀਤੇ ਸਿਰਲੇਖ ਨਾਂ: Access-Control-Request-Headers ਤੋਂ ਸਿਰਲੇਖਾਂ ਦੇ ਨਾਮ, ਜੋ ਕੋਮਾ ਜਾਂ ਲਾਈਨਾਂ ਦੁਆਰਾ ਵੱਖ ਕੀਤੇ ਹੋਣ (ਉਦਾਹਰਨ: Content-Type, Authorization)। ਗਲਤ ਨਾਮ ਹੋਣ 'ਤੇ ""‹header›" ਇੱਕ ਵੈਧ HTTP ਬੇਨਤੀ ਸਿਰਲੇਖ ਨਾਮ ਨਹੀਂ ਹੈ।" ਗਲਤੀ ਆਉਂਦੀ ਹੈ।
• ਪ੍ਰਮਾਣ ਪੱਤਰ ਸ਼ਾਮਲ ਕਰੋ: ਇੱਕ ਟੌਗਲ ਬਟਨ ਜੋ ਇਹ ਦੱਸਦਾ ਹੈ ਕਿ ਕੀ ਬੇਨਤੀ ਵਿੱਚ ਕੂਕੀਜ਼ ਜਾਂ HTTP ਪ੍ਰਮਾਣਿਕਤਾ ਸ਼ਾਮਲ ਹੈ।

ਜੇਕਰ ਇਨਪੁਟ ਵਿੱਚ ਕੋਈ ਹੋਰ ਸਮੱਸਿਆ ਹੈ, ਤਾਂ ਟੂਲ "ਹਾਈਲਾਈਟ ਕੀਤੇ ਇਨਪੁਟ ਨੂੰ ਠੀਕ ਕਰੋ ਅਤੇ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰੋ।" ਸੁਨੇਹਾ ਦਿਖਾਉਂਦਾ ਹੈ।

ਬ੍ਰਾਊਜ਼ਰ ਦੇ ਫੈਸਲੇ ਅਤੇ ਵਿਸ਼ਲੇਸ਼ਣ

ਟੂਲ ਤੁਹਾਡੇ ਦੁਆਰਾ ਦਿੱਤੇ ਗਏ ਵੇਰਵਿਆਂ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਦਾ ਹੈ ਅਤੇ ਹੇਠ ਲਿਖੇ ਨਤੀਜੇ ਪ੍ਰਦਰਸ਼ਿਤ ਕਰਦਾ ਹੈ:

1. ਪੇਸਟ ਕੀਤੇ CORS ਜਵਾਬ ਦੁਆਰਾ ਇਜਾਜ਼ਤ ਦਿੱਤੀ ਗਈ ਹੈ।: ਜਦੋਂ ਸਾਰੇ ਨਿਯਮ ਸਹੀ ਤਰ੍ਹਾਂ ਪਾਸ ਹੋ ਜਾਂਦੇ ਹਨ।
2. ਪੇਸਟ ਕੀਤੇ CORS ਜਵਾਬ ਦੁਆਰਾ ਬਲੌਕ ਕੀਤਾ ਗਿਆ।: ਜਦੋਂ CORS ਨੀਤੀ ਬੇਨਤੀ ਨੂੰ ਰੋਕਦੀ ਹੈ।
3. ਸਿਰਲੇਖ ਪਾਸ ਹੁੰਦੇ ਹਨ, ਪਰ ਪ੍ਰੀਫਲਾਈਟ ਦੀ ਸਥਿਤੀ ਪਤਾ ਨਹੀਂ ਹੈ.: ਜਦੋਂ ਸਿਰਲੇਖ ਸਹੀ ਹੁੰਦੇ ਹਨ ਪਰ ਪ੍ਰੀਫਲਾਈਟ ਸਥਿਤੀ ਅਣਜਾਣ ਹੁੰਦੀ ਹੈ।
4. ਜਵਾਬ ਅਤੇ ਬੇਨਤੀ ਵੇਰਵੇ ਦਾਖਲ ਕਰੋ, ਉਸਤੋਂ ਬਾਅਦ CORS ਨੀਤੀ ਦੀ ਜਾਂਚ ਕਰੋ।: ਜਦੋਂ ਕੋਈ ਇਨਪੁਟ ਨਹੀਂ ਦਿੱਤਾ ਗਿਆ ਹੁੰਦਾ।
5. ਇਸ ਦੀ CORS ਨੀਤੀ ਦੀ ਜਾਂਚ ਕਰਨ ਲਈ ਜਵਾਬ ਚਿਪਕਾਓ।: ਟੂਲ ਦੀ ਸ਼ੁਰੂਆਤੀ ਸਥਿਤੀ।

ਇਸ ਤੋਂ ਇਲਾਵਾ, ਟੂਲ ਪਾਰਸ ਕੀਤੇ ਗਏ Access-Control-* ਖੇਤਰਾਂ ਨੂੰ ਵੀ ਪ੍ਰਦਰਸ਼ਿਤ ਕਰਦਾ ਹੈ।

CORS ਨਿਯਮ ਅਤੇ ਵਿਸ਼ੇਸ਼ ਸਥਿਤੀਆਂ

CORS ਨੀਤੀ ਦੇ ਮੁਲਾਂਕਣ ਦੌਰਾਨ ਕਈ ਮਹੱਤਵਪੂਰਨ ਤਕਨੀਕੀ ਨਿਯਮ ਲਾਗੂ ਹੁੰਦੇ ਹਨ:

• ਪ੍ਰਮਾਣ ਪੱਤਰ ਅਤੇ ਵਾਈਲਡਕਾਰਡ: ਜਦੋਂ ਬੇਨਤੀ ਵਿੱਚ ਪ੍ਰਮਾਣ ਪੱਤਰ (credentials) ਸ਼ਾਮਲ ਹੁੰਦੇ ਹਨ, ਤਾਂ Access-Control-Allow-Origin ਦਾ ਮੁੱਲ ਵਾਈਲਡਕਾਰਡ * ਨਹੀਂ ਹੋ ਸਕਦਾ। ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਵਾਈਲਡਕਾਰਡ ਆਪਣਾ ਵਿਸ਼ੇਸ਼ ਅਰਥ ਗੁਆ ਦਿੰਦੇ ਹਨ।
• ਮਲਟੀਪਲ ਮੁੱਲ: ਜੇਕਰ Access-Control-Allow-Origin ਵਿੱਚ ਕਈ ਮੁੱਲ ਹਨ ਜਾਂ ਇਹ ਕੋਮਾ ਨਾਲ ਵੱਖ ਕੀਤੇ ਗਏ ਹਨ, ਤਾਂ ਇਸਨੂੰ ਅਵੈਧ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ।
• ਪ੍ਰਮਾਣ ਪੱਤਰਾਂ ਦੀ ਲੋੜ: ਪ੍ਰਮਾਣਿਤ ਬੇਨਤੀਆਂ ਲਈ Access-Control-Allow-Credentials ਦਾ ਬਿਲਕੁਲ true ਹੋਣਾ ਲਾਜ਼ਮੀ ਹੈ।
• Authorization ਸਿਰਲੇਖ: ਜੇਕਰ ਬੇਨਤੀ ਵਿੱਚ Authorization ਸਿਰਲੇਖ ਸ਼ਾਮਲ ਹੈ, ਤਾਂ ਇਸਨੂੰ Access-Control-Allow-Headers ਵਿੱਚ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਸੂਚੀਬੱਧ ਕਰਨਾ ਲਾਜ਼ਮੀ ਹੈ। ਭਾਵੇਂ Access-Control-Allow-Headers: * ਮੌਜੂਦ ਹੋਵੇ, ਫਿਰ ਵੀ ਇਹ Authorization ਨੂੰ ਕਵਰ ਨਹੀਂ ਕਰਦਾ।
• ਪ੍ਰੀਫਲਾਈਟ ਸਥਿਤੀ: ਜੇਕਰ ਪ੍ਰੀਫਲਾਈਟ ਜਵਾਬ ਵਿੱਚ ਕੋਈ HTTP ਸਥਿਤੀ ਲਾਈਨ (status line) ਨਹੀਂ ਹੈ, ਤਾਂ ਨਤੀਜਾ ਅਨਿਸ਼ਚਿਤ (indeterminate) ਹੋਵੇਗਾ ਕਿਉਂਕਿ ਲੋੜੀਂਦੀ 2xx ਸਥਿਤੀ ਦੀ ਜਾਂਚ ਨਹੀਂ ਕੀਤੀ ਜਾ ਸਕਦੀ।

ਪ੍ਰੋਸੈਸਿੰਗ ਅਤੇ ਗੋਪਨੀਯਤਾ

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

ਸੀਮਾਵਾਂ

ਇਹ ਬ੍ਰਾਊਜ਼ਰ CORS ਨਿਯਮਾਂ ਦੇ ਵਿਰੁੱਧ ਇੱਕ ਪੇਸਟ ਕੀਤੇ ਜਵਾਬ ਦੀ ਜਾਂਚ ਕਰਦਾ ਹੈ। ਇਹ ਸਰਵਰ ਨਾਲ ਸੰਪਰਕ ਨਹੀਂ ਕਰਦਾ, ਯੂਆਰਐਲ (URLs) ਨਹੀਂ ਪੜ੍ਹਦਾ, ਕੂਕੀਜ਼ ਸੈੱਟ ਨਹੀਂ ਕਰਦਾ, DNS/TLS ਦੀ ਜਾਂਚ ਨਹੀਂ ਕਰਦਾ, ਜਾਂ ਸਰਵਰ ਸੰਰਚਨਾਵਾਂ ਨੂੰ ਨਹੀਂ ਬਦਲਦਾ। ਇੱਕ ਪਾਸ ਹੋਣ ਵਾਲਾ ਨਤੀਜਾ ਕੇਵਲ ਪੇਸਟ ਕੀਤੇ ਜਵਾਬ ਅਤੇ ਏਥੇ ਦਾਖਲ ਕੀਤੀ ਬੇਨਤੀ ਦੇ ਵੇਰਵਿਆਂ ਨੂੰ ਕਵਰ ਕਰਦਾ ਹੈ; ਇਹ ਰੀਡਾਇਰੈਕਟ, ਕੈਸ਼ ਕੀਤੇ ਜਵਾਬ, ਸਰਵਰ ਨਿਯਮਾਂ ਨੂੰ ਬਦਲਣਾ, ਬ੍ਰਾਊਜ਼ਰ ਐਕਸਟੈਂਸ਼ਨਾਂ, ਜਾਂ ਪ੍ਰੀਫਲਾਈਟ ਤੋਂ ਬਾਅਦ ਅਸਲ ਪ੍ਰਤੀਕ੍ਰਿਆ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਨਹੀਂ ਰੱਖਦਾ।

ਅਕਸਰ ਪੁੱਛੇ ਜਾਣ ਵਾਲੇ ਸਵਾਲ (FAQ)

ਕੀ ਮੈਨੂੰ ਅਸਲ ਜਵਾਬ ਜਾਂ ਪ੍ਰੀਫਲਾਈਟ ਜਵਾਬ ਪੇਸਟ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ?

ਇਹ ਜਾਂਚ ਕਰਨ ਲਈ ਅਸਲ ਜਵਾਬ ਦੀ ਵਰਤੋਂ ਕਰੋ ਕਿ ਕੀ ਬ੍ਰਾਊਜ਼ਰ ਕੋਡ ਇੱਕ ਜਵਾਬ ਪੜ੍ਹ ਸਕਦਾ ਹੈ। OPTIONS ਜਵਾਬ ਲਈ ਪ੍ਰੀਫਲਾਈਟ ਜਵਾਬ ਦੀ ਵਰਤੋਂ ਕਰੋ ਜੋ ਬਾਅਦ ਦੀ ਵਿਧੀ ਅਤੇ ਇਸ ਦੇ ਬੇਨਤੀ ਕੀਤੇ ਸਿਰਲੇਖ ਦੇ ਨਾਵਾਂ ਨੂੰ ਮਨਜ਼ੂਰੀ ਦਿੰਦਾ ਹੈ।

ਵਾਈਲਡ ਕਾਰਡ ਪ੍ਰਮਾਣ ਪੱਤਰਾਂ ਨਾਲ ਅਸਫਲ ਕਿਉਂ ਹੋ ਸਕਦਾ ਹੈ?

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

ਕੀ ਇੱਕ ਪਾਸ ਹੋਣ ਵਾਲਾ ਨਤੀਜਾ ਇਹ ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਲਾਈਵ ਬੇਨਤੀ ਕੰਮ ਕਰੇਗੀ?

ਨਹੀਂ। ਇਹ ਨਤੀਜਾ ਕੇਵਲ ਪੇਸਟ ਕੀਤੇ ਜਵਾਬ ਅਤੇ ਏਥੇ ਦਾਖਲ ਕੀਤੀ ਬੇਨਤੀ ਦੇ ਵੇਰਵਿਆਂ ਨੂੰ ਕਵਰ ਕਰਦਾ ਹੈ। ਰੀਡਾਇਰੈਕਟ, ਕੈਸ਼ ਕੀਤੇ ਜਵਾਬ, ਸਰਵਰ ਨਿਯਮਾਂ ਨੂੰ ਬਦਲਣਾ, ਬ੍ਰਾਊਜ਼ਰ ਐਕਸਟੈਂਸ਼ਨਾਂ ਅਤੇ ਪ੍ਰੀਫਲਾਈਟ ਤੋਂ ਬਾਅਦ ਅਸਲ ਪ੍ਰਤੀਕ੍ਰਿਆ ਅਜੇ ਵੀ ਨਤੀਜੇ ਨੂੰ ਬਦਲ ਸਕਦੀ ਹੈ।