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

ਟਨਲ ਕਿਸੇ ਉਪ-ਸਰੋਤ ਨੂੰ ਕਿਉਂ ਨਹੀਂ ਢੱਕ ਸਕਦੀ

ਮਿਸ਼ਰਤ ਸਮੱਗਰੀ ਦੀ ਸ਼ੁਰੂਆਤ ਅਜਿਹੇ HTTPS ਦਸਤਾਵੇਜ਼ ਨਾਲ ਹੁੰਦੀ ਹੈ ਜੋ ਸਾਧਾਰਨ HTTP ਉੱਤੇ ਉਪ-ਸਰੋਤ ਮੰਗਦਾ ਹੈ। ਹਰ URL ਦਾ ਮੁਲਾਂਕਣ ਇਸਦੀ ਆਪਣੀ ਸਕੀਮ ਉੱਤੇ ਹੁੰਦਾ ਹੈ, ਇਸ ਲਈ ਮੂਲ ਦਸਤਾਵੇਜ਼ ਦੀ ਸੁਰੱਖਿਆ ਕਦੇ ਵੀ ਸੰਤਾਨ ਬੇਨਤੀ ਤੱਕ ਨਹੀਂ ਫੈਲਦੀ। ਬ੍ਰਾਊਜ਼ਰ ਦੇ ਹੇਠਾਂ ਜੋੜਿਆ ਐਨਕ੍ਰਿਪਸ਼ਨ ਤਾਰ ਉੱਤੇ ਜਾਣ ਵਾਲੀ ਚੀਜ਼ ਬਦਲਦਾ ਹੈ, ਉਹ http:// ਨਹੀਂ ਜੋ ਮਾਰਕਅਪ ਨੇ ਮੰਗਿਆ ਸੀ।

ਮੌਜੂਦਾ ਬ੍ਰਾਊਜ਼ਰ ਇਹਨਾਂ ਬੇਨਤੀਆਂ ਨੂੰ ਦੋ ਗਰੁੱਪਾਂ ਵਿੱਚ ਵੰਡਦੇ ਹਨ ਅਤੇ ਵੱਖਰੇ ਢੰਗ ਨਾਲ ਸੰਭਾਲਦੇ ਹਨ। ਸਕ੍ਰਿਪਟਾਂ, ਸਟਾਈਲਸ਼ੀਟਾਂ, iframe ਅਤੇ fetch, XMLHttpRequest ਜਾਂ WebSocket ਰਾਹੀਂ ਕੀਤੀਆਂ ਕਾਲਾਂ ਸਿੱਧੀਆਂ ਰੱਦ ਕਰ ਦਿੱਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਪਹਿਲਾਂ ਕੋਈ ਅਪਗ੍ਰੇਡ ਕੋਸ਼ਿਸ਼ ਬਿਨਾਂ। ਤਸਵੀਰਾਂ, ਆਡੀਓ ਅਤੇ ਵੀਡੀਓ https:// ਵਿੱਚ ਦੁਬਾਰਾ ਲਿਖੇ ਜਾਂਦੇ ਹਨ ਅਤੇ ਦੁਬਾਰਾ ਮੰਗੇ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਜਦੋਂ ਉਹ ਸੁਰੱਖਿਅਤ ਪ੍ਰਾਪਤੀ ਫੇਲ੍ਹ ਹੁੰਦੀ ਹੈ ਤਾਂ ਲੋਡਿੰਗ ਛੱਡ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ। ਜਿਸ ਉਪ-ਸਰੋਤ ਦਾ ਹੋਸਟ ਨੰਗਾ IP ਪਤਾ ਹੈ ਉਸ URL ਨੂੰ ਅਪਗ੍ਰੇਡ ਤੋਂ ਛੋਟ ਹੈ, ਇਸ ਲਈ IP ਹੋਸਟ ਉੱਤੇ HTTP ਤਸਵੀਰ ਚੁੱਪਚਾਪ ਠੀਕ ਹੋਣ ਦੀ ਬਜਾਏ ਰੋਕੀ ਰਹਿੰਦੀ ਹੈ। ਇਹ ਵੰਡ, ਅਪਗ੍ਰੇਡ ਹੋ ਸਕਣ ਵਾਲੇ ਪਾਸੇ ਦੀ ਉਸ ਛੋਟ ਸਮੇਤ, ਇੱਥੇ ਦਸਤਾਵੇਜ਼ੀ ਹੈ: Mozilla ਦੀ ਮਿਸ਼ਰਤ ਸਮੱਗਰੀ ਗਾਈਡ ਵਿੱਚ। Chrome ਸੁਰੱਖਿਅਤ ਪੰਨੇ ਤੋਂ ਸ਼ੁਰੂ ਹੋਣ ਵਾਲੇ ਅਸੁਰੱਖਿਅਤ ਡਾਊਨਲੋਡ ਉੱਤੇ ਵੀ ਅਜਿਹਾ ਹੀ ਇਨਕਾਰ ਲਾਗੂ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ PDF ਲਿੰਕ ਮਰ ਸਕਦਾ ਹੈ ਜਦੋਂ ਕਿ ਆਲੇ-ਦੁਆਲੇ ਦਾ ਪੰਨਾ ਸਾਬਤ ਦਿਸਦਾ ਹੈ।

ਇਸ ਲਈ ਸਲੇਟੀ ਕਤਾਰ ਨਿਯੰਤਰਣ ਕੰਮ ਕਰ ਰਿਹਾ ਹੋਣ ਦਾ ਸਬੂਤ ਹੈ, ਟਨਲ ਨੇ ਸਾਧਾਰਨ ਟੈਕਸਟ ਛੱਡਿਆ ਹੋਣ ਦਾ ਸਬੂਤ ਨਹੀਂ। ਕਤਾਰ ਨੂੰ ਇੱਕ ਹਵਾਲੇ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਨ ਵਾਲੀ ਖੋਜ ਮੰਨੋ, ਪੂਰੇ ਪੰਨੇ ਵੱਲ ਨਹੀਂ।

ਨਿਰਧਾਰਤ ਕਰੋ ਕਿ ਅਸੁਰੱਖਿਅਤ ਹਵਾਲਾ ਕਿਸਦਾ ਹੈ

ਕੁਝ ਵੀ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਸਮੱਸਿਆ ਵਾਲੀ URL ਨੂੰ ਇਸ ਆਧਾਰ 'ਤੇ ਤਰਤੀਬ ਦਿਓ ਕਿ ਇਹ ਕਿੱਥੇ ਬਣਦੀ ਹੈ। ਉਹੀ ਜਵਾਬ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਅੱਜ ਸੁਧਾਰ ਜਾਰੀ ਕਰ ਸਕਦੇ ਹੋ, ਕੋਈ ਵਿਕਰੇਤਾ ਇੱਕ ਜਾਰੀ ਕਰੇਗਾ, ਜਾਂ ਨਿਰਭਰਤਾ ਨੂੰ ਪੰਨਾ ਛੱਡਣਾ ਪਵੇਗਾ। ਇਸਨੂੰ ਨੈੱਟਵਰਕ ਪੈਨਲ ਦੇ Initiator ਕਾਲਮ ਵਿੱਚ ਪੜ੍ਹੋ, ਕਿਉਂਕਿ ਸਕ੍ਰੀਨ ਉੱਤੇ ਮਾਰਕਅਪ ਅਕਸਰ ਰਨਟਾਈਮ ਵਿੱਚ ਜੋੜਿਆ ਜਾਂਦਾ ਹੈ।

URL ਕਿੱਥੋਂ ਆਉਂਦੀ ਹੈਇਸਨੂੰ ਕੌਣ ਠੀਕ ਕਰ ਸਕਦਾ ਹੈਪਹਿਲਾ ਕਦਮ
ਤੁਹਾਡੇ ਵੱਲੋਂ ਤੈਨਾਤ ਕੀਤੇ ਟੈਂਪਲੇਟ ਜਾਂ ਹਿੱਸੇ ਵਿੱਚ ਸਖ਼ਤ-ਕੋਡਿਤਤੁਸੀਂਇਸਨੂੰ https:// ਰੂਪ ਨਾਲ ਬਦਲੋ ਅਤੇ ਫਿਰ ਕੈਸ਼ ਸਾਫ਼ ਕਰੋ
ਟੈਗ ਮੈਨੇਜਰ ਜਾਂ ਵਿਕਰੇਤਾ ਬੰਡਲ ਵੱਲੋਂ ਪਾਇਆ ਗਿਆਵਿਕਰੇਤਾ, ਤੁਹਾਡੀ ਟਿਕਟ ਨਾਲਸਹੀ URL, ਬੇਨਤੀ ਕਿਸਮ ਅਤੇ ਕੰਸੋਲ ਲਾਈਨ ਭੇਜੋ
ਸਿਰਫ਼ ਪੋਰਟ 80 ਉੱਤੇ TLS ਸਰੋਤੇ ਤੋਂ ਬਿਨਾਂ ਪਰੋਸਿਆ ਜਾਂਦਾ ਹੈਹੋਸਟ ਦਾ ਮਾਲਕTLS ਮੰਗੋ, ਤੁਹਾਡੀ ਨਿਯੰਤਰਿਤ ਚੀਜ਼ ਅੱਗੇ ਰੱਖੋ, ਜਾਂ ਇਸਨੂੰ ਛੱਡ ਦਿਓ

ਜਦੋਂ ਹੋਸਟ ਪਹਿਲਾਂ ਹੀ 443 ਉੱਤੇ ਜਵਾਬ ਦਿੰਦਾ ਹੈ ਅਤੇ ਸਿਰਫ਼ ਹਵਾਲਾ http ਕਹਿੰਦਾ ਹੈ, ਤਾਂ ਸੁਧਾਰ ਸਥਾਨਕ ਹੈ: ਹਵਾਲਾ ਬਦਲੋ, ਪੰਨੇ ਦਾ ਕੈਸ਼ ਸਾਫ਼ ਕਰੋ ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਕਤਾਰ https ਬਣ ਗਈ ਹੈ। ਸਿਰਫ਼ ਪੋਰਟ 80 ਉੱਤੇ ਸੁਣਨ ਵਾਲਾ ਹੋਸਟ ਸੰਪਾਦਨ ਨਾਲ ਅਨੁਕੂਲ ਨਹੀਂ ਬਣਾਇਆ ਜਾ ਸਕਦਾ, ਇਸ ਲਈ ਸਰੋਤ ਥਾਂ ਬਦਲਦਾ ਹੈ, ਇਸਦੇ ਅੱਗੇ ਤੁਹਾਡੀ ਨਿਯੰਤਰਿਤ ਚੀਜ਼ ਰੱਖੀ ਜਾਂਦੀ ਹੈ, ਜਾਂ ਇਹ ਗਾਇਬ ਹੋ ਜਾਂਦਾ ਹੈ। ਟੈਗ ਮੈਨੇਜਰ ਵੱਲੋਂ ਪਾਈ URL ਤੁਹਾਡੇ ਆਪਣੇ ਟੈਂਪਲੇਟ ਦੇ ਸਾਫ਼ ਹੋਣ 'ਤੇ ਵੀ ਦਿਸਦੀ ਰਹਿੰਦੀ ਹੈ, ਅਤੇ ਉਹ ਕੇਸ ਅਜਿਹੀ ਟਿਕਟ ਦਾ ਹੈ ਜਿਸ ਨਾਲ ਸਹੀ URL ਅਤੇ ਕੰਸੋਲ ਲਾਈਨ ਜੁੜੀ ਹੋਵੇ। ਕਰਮਚਾਰੀਆਂ ਨੂੰ ਅਸੁਰੱਖਿਅਤ ਸਮੱਗਰੀ ਦੀ ਇਜਾਜ਼ਤ ਦੇਣ ਲਈ ਕਹਿਣਾ ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵਿਕਲਪ ਨਹੀਂ, ਕਿਉਂਕਿ ਇਹ ਉਸ ਬ੍ਰਾਊਜ਼ਰ ਪ੍ਰੋਫਾਈਲ ਵੱਲੋਂ ਦੇਖੀ ਜਾਣ ਵਾਲੀ ਹਰ ਸਾਈਟ ਲਈ ਜਾਂਚ ਬੰਦ ਕਰ ਦਿੰਦਾ ਹੈ।

ਬ੍ਰਾਊਜ਼ਰ ਸੈਟਿੰਗ ਨਹੀਂ, ਹਵਾਲਾ ਠੀਕ ਕਰੋ

ਫੇਲ੍ਹ ਹੋ ਰਹੇ ਪ੍ਰਵਾਹ ਨੂੰ ਨੈੱਟਵਰਕ ਲੌਗ ਸੰਭਾਲ ਕੇ ਦੁਬਾਰਾ ਲੋਡ ਕਰੋ ਅਤੇ ਪੈਨਲ ਨੂੰ ਉਸ ਹੋਸਟ ਮੁਤਾਬਕ ਫਿਲਟਰ ਕਰੋ ਜਿਸ 'ਤੇ ਸ਼ੱਕ ਹੈ। ਕੰਸੋਲ URL ਅਤੇ ਨਿਰਦੇਸ਼ ਦਾ ਨਾਮ ਲੈਂਦਾ ਹੈ, ਜੋ ਟੈਂਪਲੇਟ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਬੇਨਤੀ ਰੱਦ ਹੋਈ ਜਾਂ ਅਪਗ੍ਰੇਡ।

curl -sSI https://cdn.example.org/vendor.js | head -n 1
curl -sS -o /dev/null -w '%{http_code} %{url_effective}\n' -L https://cdn.example.org/vendor.js

ਦੋ ਸਹਾਇਕ ਨਿਯੰਤਰਣ ਜਾਣਨ ਯੋਗ ਹਨ ਅਤੇ ਦੋਹਾਂ ਵਿੱਚੋਂ ਕੋਈ ਸੁਧਾਰ ਦਾ ਵਿਕਲਪ ਨਹੀਂ। Content-Security-Policy ਹੈਡਰ ਜਿਸ ਵਿੱਚ upgrade-insecure-requests ਬ੍ਰਾਊਜ਼ਰ ਨੂੰ ਪੰਨਾ ਛੱਡਣ ਤੋਂ ਪਹਿਲਾਂ http ਉਪ-ਸਰੋਤ URL ਦੁਬਾਰਾ ਲਿਖਣ ਲਈ ਮਜਬੂਰ ਕਰਦਾ ਹੈ, ਜੋ ਤੁਹਾਡੇ ਵੱਲੋਂ ਅਜੇ ਨਾ ਲੱਭੇ ਪੁਰਾਣੇ ਹਵਾਲੇ ਫੜਦਾ ਹੈ। ਦੁਬਾਰਾ ਲਿਖੀ ਬੇਨਤੀ ਟੀਚਾ ਹੋਸਟ HTTPS ਨਾ ਦੇਣ 'ਤੇ ਵੀ ਫੇਲ੍ਹ ਹੁੰਦੀ ਹੈ, ਇਸ ਲਈ ਹੈਡਰ ਸਿਰਫ਼ ਇਹ ਬਦਲਦਾ ਹੈ ਕਿ ਬ੍ਰਾਊਜ਼ਰ ਕਿਹੜੀ URL ਅਜ਼ਮਾਉਂਦਾ ਹੈ। HSTS ਹਰ ਹੋਸਟ ਉੱਤੇ ਲਾਗੂ ਹੁੰਦਾ ਹੈ, ਭਾਵ ਤੁਹਾਡੇ ਆਪਣੇ ਡੋਮੇਨ ਦੀ ਨੀਤੀ ਅਜਿਹੇ ਤੀਜੀ ਧਿਰ ਦੇ CDN ਲਈ ਕੁਝ ਨਹੀਂ ਕਰਦੀ ਜਿਸਨੇ ਇਹ ਹੈਡਰ ਕਦੇ ਨਹੀਂ ਭੇਜਿਆ। ਟੈਂਪਲੇਟ ਬਦਲਣ ਤੋਂ ਬਾਅਦ ਪੰਨੇ ਦਾ ਕੈਸ਼ ਸਾਫ਼ ਕਰੋ ਅਤੇ ਰੈਂਡਰ ਕੀਤੇ HTML ਵਿੱਚ ਪੁਰਾਣਾ ਹੋਸਟ ਨਾਮ ਲੱਭੋ, ਕਿਉਂਕਿ ਉਹੀ URL ਕਿਸੇ ਹਿੱਸੇ, ਅਨੁਵਾਦ ਸਤਰ ਜਾਂ ਡੇਟਾਬੇਸ ਫੀਲਡ ਰਾਹੀਂ ਵੀ ਆ ਸਕਦੀ ਹੈ।

ਰੀਡਾਇਰੈਕਟ ਵੀ ਟਰੈਕ ਕਰੋ, ਕਿਉਂਕਿ https:// ਨਾਲ ਸ਼ੁਰੂ ਹੋਣ ਵਾਲੀ ਲੜੀ http:// ਥਾਂ 'ਤੇ ਉਤਰ ਸਕਦੀ ਹੈ ਅਤੇ ਬ੍ਰਾਊਜ਼ਰ ਆਖਰੀ ਛਾਲ ਦਾ ਫੈਸਲਾ ਕਰਦਾ ਹੈ। ਦੂਜੀ ਕਮਾਂਡ ਦੀ -L ਸ਼ਕਲ ਉੱਪਰ ਵਾਲੀ ਉਹ ਪ੍ਰਭਾਵੀ URL ਤੁਹਾਡੇ ਲਈ ਛਾਪਦੀ ਹੈ। ਜੇ ਆਖਰੀ ਛਾਲ ਸ਼ੁੱਧ http ਹੈ, ਤਾਂ ਹਵਾਲਾ ਅਜੇ ਵੀ ਗਲਤ ਹੈ ਭਾਵੇਂ ਤੁਹਾਡਾ ਸੰਪਾਦਿਤ ਲਿੰਕ ਠੀਕ ਲੱਗਦਾ ਸੀ।

ਕੰਸੋਲ ਅਤੇ ਨੈੱਟਵਰਕ ਪੈਨਲ ਨਾਲ ਪੰਨੇ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ

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

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

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

ਸੰਬੰਧਿਤ ਲੇਖ