ਕੀ VPN ਜਾਂ ਪ੍ਰੌਕਸੀ ਕਾਪੀਰਾਈਟ ਵਾਲੀ ਸਮੱਗਰੀ ਦੀ ਨਕਲ ਕਰ ਸਕਦੀ ਹੈ? ਤਿੰਨ ਕਾਰਵਾਈਆਂ
ਪੈਕਟ ਭੇਜਣਾ, ਜਵਾਬ ਕੈਸ਼ ਕਰਨਾ ਅਤੇ ਦੁਬਾਰਾ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਨਾ ਵੱਖਰੇ ਕਾਪੀਰਾਈਟ ਸਵਾਲ ਖੜ੍ਹੇ ਕਰਦੇ ਹਨ। ਤੁਹਾਡੀ ਸੇਵਾ ਜੋ ਕਾਰਵਾਈ ਕਰਦੀ ਹੈ, ਉਸਨੂੰ ਉਸ ਨੂੰ ਨਿਯੰਤਰਿਤ ਕਰਨ ਵਾਲੇ ਨਿਯਮ ਨਾਲ ਜੋੜੋ।
ਪੈਕਟ ਭੇਜਣਾ, ਕੈਸ਼ ਕਰਨਾ ਅਤੇ ਦੁਬਾਰਾ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਨਾ ਡੈਸ਼ਬੋਰਡ ਤੋਂ ਇੱਕੋ ਜਿਹੇ ਦਿਖਦੇ ਹਨ, ਪਰ ਹੱਕ ਦਾ ਸਵਾਲ ਆਉਣ ’ਤੇ ਬਿਲਕੁਲ ਵੱਖਰਾ ਵਿਵਹਾਰ ਕਰਦੇ ਹਨ। ਵਰਤੋਂਕਾਰ ਅਤੇ ਸਰਵਰ ਵਿਚਕਾਰ ਬਾਈਟ ਸਾਰਨ ਵਾਲੀ ਸੇਵਾ ਇੱਕ ਕਾਰਵਾਈ ਕਰਦੀ ਹੈ, ਜਦਕਿ ਜਵਾਬ ਰੱਖ ਕੇ ਅਗਲੇ ਆਉਣ ਵਾਲੇ ਨੂੰ ਦੇਣ ਵਾਲੀ ਸੇਵਾ ਦੂਜੀ ਕਾਰਵਾਈ ਕਰਦੀ ਹੈ। ਕਿਸੇ ਹੋਰ ਦੀ ਸਮੱਗਰੀ ਆਪਣੇ ਨਾਂ ਹੇਠ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਨਾ ਤੀਜੀ ਕਾਰਵਾਈ ਹੈ, ਅਤੇ ਆਮ ਅਰਥਾਂ ਵਿੱਚ ਵੰਡ ਸਿਰਫ਼ ਉਹੀ ਤੀਜੀ ਕਾਰਵਾਈ ਹੈ।
ਪਤਾ ਲਗਾਓ ਕਿ ਤੁਹਾਡਾ ਸਿਸਟਮ ਉਹਨਾਂ ਤਿੰਨਾਂ ਵਿੱਚੋਂ ਕਿਹੜੀ ਕਾਰਵਾਈ ਅਸਲ ਵਿੱਚ ਕਰਦਾ ਹੈ, ਫਿਰ ਉਸ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਨਿਯਮ ਜੋੜੋ। ਉਤਪਾਦ ਦੇ ਲੇਬਲ ਇੱਥੇ ਕੁਝ ਵੀ ਤੈਅ ਨਹੀਂ ਕਰਦੇ, ਅਤੇ ਵਰਤਿਆ ਜਾਣ ਵਾਲਾ ਪ੍ਰੋਟੋਕਾਲ ਵੀ ਮਾਪਦੰਡ ਨਹੀਂ।
ਪ੍ਰੌਕਸੀ ਜਾਂ VPN ਦੁਆਰਾ ਕੀਤੀਆਂ ਜਾ ਸਕਣ ਵਾਲੀਆਂ ਤਿੰਨ ਕਾਰਵਾਈਆਂ
ਗੇਟਵੇ TCP ਪ੍ਰਵਾਹ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ, ਪਤੇ ਦੁਬਾਰਾ ਲਿਖਦਾ ਹੈ ਅਤੇ ਭਾਗ ਦੋਵਾਂ ਦਿਸ਼ਾਵਾਂ ਵਿੱਚ ਅੱਗੇ ਭੇਜਦਾ ਹੈ। ਸੰਪਰਕ ਤੋਂ ਬਾਅਦ ਡਿਸਕ ’ਤੇ ਕੁਝ ਨਹੀਂ ਰਹਿੰਦਾ, ਅਤੇ ਜੇ ਗਾਹਕ ਮੂਲ ਨਾਲ ਨਹੀਂ ਸਗੋਂ ਗੇਟਵੇ ਨਾਲ TLS ਗੱਲਬਾਤ ਨਾ ਕਰੇ ਤਾਂ ਪੇਲੋਡ ਗੇਟਵੇ ਲਈ ਅਪਾਰਦਰਸ਼ੀ ਰਹਿੰਦਾ ਹੈ।
ਕੈਸ਼ ਕਰਨ ਵਾਲਾ ਵਿਚੋਲਾ ਵੱਖਰੇ ਢੰਗ ਨਾਲ ਕੰਮ ਕਰਦਾ ਹੈ: ਇਹ ਬੇਨਤੀ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਦਾ ਹੈ, ਆਪਣੇ ਆਪ ਗਿਣੇ ਜਾਂ ਹੈਡਰਾਂ ਤੋਂ ਪੜ੍ਹੇ ਸਮੇਂ ਤੱਕ ਜਵਾਬ ਸੰਭਾਲਦਾ ਹੈ, ਅਤੇ ਫਿਰ ਉਹ ਸੰਭਾਲੀ ਵਸਤੂ ਅਗਲੇ ਗਾਹਕਾਂ ਨੂੰ ਦੁਬਾਰਾ ਦਿੰਦਾ ਹੈ। ਹੁਣ ਤਾਰ ਤੋਂ ਬਾਹਰ ਕੁਝ ਮੌਜੂਦ ਹੈ, URL ਅਤੇ ਪ੍ਰਮਾਣਕ ਦੁਆਰਾ ਨਿਸ਼ਾਨਿਤ, ਅਤੇ ਇਸਦਾ ਸੰਭਾਲਣਾ ਮਾਮੂਲੀ ਅਸਰ ਨਹੀਂ ਸਗੋਂ ਸੰਰਚਨਾ ਦੀ ਚੋਣ ਹੈ।
ਦੁਬਾਰਾ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਨਾ ਇੱਕ ਕਦਮ ਹੋਰ ਅੱਗੇ ਜਾਂਦਾ ਹੈ। ਸਮੱਗਰੀ ਤੁਹਾਡੇ ਕੰਟਰੋਲ ਵਾਲੇ ਢਾਂਚੇ ’ਤੇ, ਤੁਹਾਡੇ ਚੁਣੇ ਦਰਸ਼ਕਾਂ ਲਈ, ਅਕਸਰ ਸੋਧ ਤੋਂ ਬਾਅਦ ਰੱਖੀ ਹੁੰਦੀ ਹੈ। ਪਹਿਲੀਆਂ ਦੋ ਕਾਰਵਾਈਆਂ ਢੋਆ-ਢੁਆਈ ਦਾ ਵਰਣਨ ਕਰਦੀਆਂ ਹਨ, ਤੀਜੀ ਵੰਡ ਦਾ।
| ਕਾਰਵਾਈ | ਬਾਅਦ ਵਿੱਚ ਕੀ ਰਹਿੰਦਾ ਹੈ | ਨਤੀਜਾ ਤੈਅ ਕਰਨ ਵਾਲਾ ਸਵਾਲ |
|---|---|---|
| ਪ੍ਰਵਾਹ ਲੈ ਜਾਣਾ | ਕੁਝ ਸਕਿੰਟ ਰਹਿਣ ਵਾਲੀ ਅਨੁਵਾਦ ਅਵਸਥਾ ਅਤੇ ਬਫਰ | ਕਿਹੜਾ ਵਿਚੋਲਾ ਨਿਯਮ ਅਸਥਾਈ ਪ੍ਰਸਾਰਣ ਨੂੰ ਕਵਰ ਕਰਦਾ ਹੈ? |
| ਜਵਾਬ ਸੰਭਾਲਣਾ | ਵਸਤੂ ਅਤੇ ਤਾਜ਼ਗੀ ਤੇ ਪ੍ਰਮਾਣਕ ਮੈਟਾਡੇਟਾ | ਕੀ ਸੰਭਾਲਣਾ ਅਤੇ ਦੁਬਾਰਾ ਚਲਾਉਣਾ ਮਨਜ਼ੂਰ ਸੀ, ਅਤੇ ਕਦੋਂ ਤੱਕ? |
| ਰਚਨਾ ਨੂੰ ਆਪਣੇ URL ਹੇਠ ਪੇਸ਼ ਕਰਨਾ | ਨਵੇਂ ਦਰਸ਼ਕਾਂ ਲਈ ਭੇਜੀ ਪ੍ਰਕਾਸ਼ਿਤ ਨਕਲ | ਉਸ ਦਰਸ਼ਕ ਲਈ ਵੰਡ ਨੂੰ ਕਿਹੜੀ ਮਨਜ਼ੂਰੀ ਕਵਰ ਕਰਦੀ ਹੈ? |
ਡੀਕ੍ਰਿਪਟ ਕਰਨ ਵਾਲੀ ਪ੍ਰੌਕਸੀ ਢੋਆ-ਢੁਆਈ ਨੂੰ ਨਕਲ ਕਿੱਥੇ ਬਦਲਦੀ ਹੈ
ਬਹੁਤੇ ਝਗੜਿਆਂ ਦਾ ਫੈਸਲਾ ਕਰਨ ਵਾਲਾ ਫ਼ਰਕ ਇਹ ਹੈ ਕਿ ਕੀ ਯੰਤਰ ਕਦੇ ਸਪਸ਼ਟ ਟੈਕਸਟ ਰੱਖਦਾ ਹੈ। ਸ਼ੁੱਧ ਸੁਰੰਗ, ਭਾਵੇਂ WireGuard ਹੋਵੇ, OpenVPN tun ਯੰਤਰ ਹੋਵੇ ਜਾਂ SSH -L ਫਾਰਵਰਡ ਹੋਵੇ, ਸਿਰਿਆਂ ਵਿਚਕਾਰ ਸਿਫ਼ਰ ਟੈਕਸਟ ਲੈ ਜਾਂਦਾ ਹੈ ਅਤੇ ਪੜ੍ਹਨ ਯੋਗ ਕੁਝ ਨਹੀਂ ਛੱਡਦਾ। TLS ਖ਼ਤਮ ਕਰਨ ਵਾਲੀ ਪ੍ਰੌਕਸੀ ਉਲਟਾ ਕੰਮ ਕਰਦੀ ਹੈ: ਇਹ ਹੈਂਡਸ਼ੇਕ ਪੂਰਾ ਕਰਦੀ ਹੈ, ਜਵਾਬ ਨੂੰ ਮੈਮੋਰੀ ਵਿੱਚ ਬਫਰ ਕਰਦੀ ਹੈ, ਫਿਰ ਸਟ੍ਰੀਮ ਨੂੰ ਗਾਹਕ ਵੱਲ ਦੁਬਾਰਾ ਐਨਕ੍ਰਿਪਟ ਕਰਦੀ ਹੈ। ਉਹਨਾਂ ਕਾਰਵਾਈਆਂ ਵਿਚਕਾਰ ਰਚਨਾ ਉਸ ਰੂਪ ਵਿੱਚ ਹੁੰਦੀ ਹੈ ਜਿਸਨੂੰ ਆਪਰੇਟਰ ਵੇਖ ਅਤੇ ਰੱਖ ਸਕਦਾ ਹੈ।
17 USC 106 ਨਕਲ ਅਤੇ ਵੰਡ ਨੂੰ ਨਿਵੇਕਲੇ ਹੱਕਾਂ ਵਿੱਚ ਗਿਣਦਾ ਹੈ, ਅਤੇ ਹਰ ਇੱਕ ਉਸੇ ਸੰਹਿਤਾ ਵਿੱਚ ਦਿੱਤੀਆਂ ਸੀਮਾਵਾਂ ਅਧੀਨ ਹੈ। ਮਿਲੀਸਕਿੰਟ ਦਾ ਬਫਰ ਬਿਨਾਂ ਬਹਿਸ ਸੀਮਾ ਵਿੱਚ ਆ ਸਕਦਾ ਹੈ; ਸੰਭਾਲੀ, ਦੁਬਾਰਾ ਚੱਲ ਸਕਣ ਵਾਲੀ ਵਸਤੂ ਨੂੰ ਉੱਥੇ ਰੱਖਣਾ ਕਾਫ਼ੀ ਔਖਾ ਹੈ। ਮਿਆਦ ਅਤੇ ਮਕਸਦ ਮੈਮੋਰੀ ਛੋਹਣ ਦੀ ਹਕੀਕਤ ਨਾਲੋਂ ਵੱਧ ਭਾਰ ਰੱਖਦੇ ਹਨ।
ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ VPN ਨੂੰ ਲਾਇਸੰਸ ਨਹੀਂ ਬਣਾਉਂਦਾ, ਅਤੇ ਹਰ ਪ੍ਰੌਕਸੀ ਨੂੰ ਉਲੰਘਣਕਾਰ ਨਹੀਂ ਬਣਾਉਂਦਾ। ਢੋਆ-ਢੁਆਈ ਕਈ ਤੱਥਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ, ਅਤੇ ਮੁਲਾਂਕਣ ਯੋਗ ਸਵਾਲ ਉਹੀ ਰਹਿੰਦਾ ਹੈ: ਕਿਹੜੀ ਕਾਰਵਾਈ, ਕਿਸਦੀ ਸਮੱਗਰੀ ’ਤੇ, ਕਿਹੜੀ ਮਨਜ਼ੂਰੀ ਹੇਠ।
ਕੈਸ਼ ਹੈਡਰ ਕਾਨੂੰਨੀ ਮਨਜ਼ੂਰੀ ਨਹੀਂ, ਪ੍ਰੋਟੋਕਾਲ ਮਨਜ਼ੂਰੀ ਦੱਸਦੇ ਹਨ
HTTP ਕੈਸ਼ ਜਵਾਬ ਦੇ ਮੈਟਾਡੇਟਾ ਤੋਂ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਕੀ ਸੰਭਾਲ ਸਕਦਾ ਹੈ, ਅਤੇ RFC 9111 ਉਹ ਨਿਯਮ ਤੈਅ ਕਰਦਾ ਹੈ ਜਿਹਨਾਂ ਦੀ ਇਹ ਪਾਲਣਾ ਕਰਦਾ ਹੈ। Cache-Control: no-store ਹਰ ਅਨੁਕੂਲ ਕੈਸ਼ ਨੂੰ ਜਵਾਬ ਸੁੱਟਣ ਲਈ ਕਹਿੰਦਾ ਹੈ, ਜਦਕਿ private ਦੁਬਾਰਾ ਵਰਤੋਂ ਨੂੰ ਇੱਕ ਵਰਤੋਂਕਾਰ ਤੱਕ ਸੀਮਿਤ ਕਰਦਾ ਹੈ ਅਤੇ ਲੰਮਾ max-age ਸਾਂਝੇ ਸੰਭਾਲ ਦਾ ਸੱਦਾ ਦਿੰਦਾ ਹੈ। ਇੱਕ ਬੇਨਤੀ ਦੱਸਦੀ ਹੈ ਕਿ ਮੂਲ ਨੇ ਕਿਹੜੀ ਨੀਤੀ ਚੁਣੀ। ਹੋਰ ਕਿਸੇ ਬਹਿਸ ਤੋਂ ਪਹਿਲਾਂ ਇਹ ਚਲਾਓ।
curl -sI https://origin.example/media/report.pdf | grep -i -E 'cache-control|etag|age'
ਲੰਮੀ ਉਮਰ ਦਾ ਐਲਾਨ ਕਰਨ ਵਾਲਾ ਜਵਾਬ ਕੈਸ਼ਾਂ ਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿ ਪ੍ਰੋਟੋਕਾਲ ਪੱਧਰ ’ਤੇ ਦੁਬਾਰਾ ਚਲਾਉਣਾ ਸਵੀਕਾਰਯੋਗ ਹੈ। ਉਹ ਬਿਆਨ ਇਸ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦਾ ਕਿ ਤੁਸੀਂ ਉਹੀ ਵਸਤੂ ਲੈ ਕੇ ਦੁਬਾਰਾ ਹੋਸਟ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਆਪਣੀ ਸੇਵਾ ਵਿੱਚ ਸ਼ਾਮਲ ਕਰ ਸਕਦੇ ਹੋ। ਦੋ ਵੱਖਰੀਆਂ ਮਨਜ਼ੂਰੀਆਂ ਦੋ ਵੱਖਰੇ ਮਕੈਨਿਜ਼ਮਾਂ ਤੋਂ ਆਉਂਦੀਆਂ ਹਨ, ਅਤੇ ਇੱਕ ਪੂਰੀ ਕਰਨ ਨਾਲ ਦੂਜੀ ਉੱਥੇ ਹੀ ਰਹਿੰਦੀ ਹੈ ਜਿੱਥੇ ਸੀ।
ਸ਼ੀਸ਼ੇ ਵਾਲਾ ਮਾਮਲਾ ਵੀ ਇਸੇ ਤਰ੍ਹਾਂ ਫੇਲ ਹੁੰਦਾ ਹੈ। ਸਿਰੇ ਤੋਂ ਸਿਰੇ ਤੱਕ HTTPS ਪਾਰਦਰਸ਼ੀ ਕੈਸ਼ ਨੂੰ ਕੁਝ ਸੰਭਾਲਣ ਤੋਂ ਰੋਕਦਾ ਹੈ, ਪਰ ਉਹ ਨਤੀਜਾ ਨਾ ਸਮੱਗਰੀ ਵੰਡਣ ਦਾ ਹੱਕ ਬਣਾਉਂਦਾ ਹੈ ਅਤੇ ਨਾ ਹੀ ਪਹਿਲਾਂ ਵਾਲਾ ਹੱਕ ਹਟਾਉਂਦਾ ਹੈ। ਪ੍ਰੋਟੋਕਾਲ ਦਾ ਵਿਵਹਾਰ ਦੱਸਦਾ ਹੈ ਕਿ ਯੰਤਰ ਕੀ ਕਰ ਸਕਦਾ ਹੈ; ਇਹ ਕਦੇ ਵੀ ਅਧਿਕਾਰ ਨਹੀਂ ਦਿੰਦਾ।
ਸੇਵਾ ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਕੀ ਲਿਖਣਾ ਚਾਹੀਦਾ ਹੈ
ਉਹ ਪ੍ਰਬੰਧ ਬਾਹਰਲੇ ਬੰਦੇ ਦੇ ਜਾਂਚਣ ਯੋਗ ਸ਼ਬਦਾਂ ਵਿੱਚ ਬਿਆਨ ਕਰੋ। ਸਮੱਗਰੀ ਅਤੇ ਇਸਦੇ ਸਰੋਤ ਦਾ ਨਾਂ ਦਿਓ, ਸਿਸਟਮ ਵੱਲੋਂ ਕੀਤੀਆਂ ਕਾਰਵਾਈਆਂ ਦੀ ਸੂਚੀ ਦਿਓ, ਅਤੇ ਦੱਸੋ ਕਿ ਹਰ ਸੰਭਾਲੀ ਵਸਤੂ ਕਿੰਨੀ ਦੇਰ ਜੀਉਂਦੀ ਹੈ।
ਉਹ ਵਰਣਨ ਕਿਸੇ ਦੀ ਯਾਦ ਵਿੱਚ ਨਹੀਂ, ਸਗੋਂ ਤੈਨਾਤੀ ਨਾਲ ਰੱਖੋ। ਸ਼ਿਕਾਇਤ ਆਉਣ ’ਤੇ ਬਚਾਅ ਯੋਗ ਸਥਿਤੀ ਅਤੇ ਅੰਦਾਜ਼ੇ ਵਿਚਕਾਰਲਾ ਫਾਸਲਾ ਆਮ ਤੌਰ ’ਤੇ ਮਹੀਨੇ ਪਹਿਲਾਂ ਲਿਖਿਆ, ਸੰਭਾਲ ਮਿਆਦ ਅਤੇ ਲਾਇਸੰਸ ਦਾ ਨਾਂ ਲੈਣ ਵਾਲਾ ਇੱਕ ਪੈਰਾ ਹੁੰਦਾ ਹੈ।
ਛੋਟੀ ਸਮੀਖਿਆ ਸੂਚੀ ਦੁਹਰਾਉਣ ਵਾਲੇ ਖੱਡੇ ਕਵਰ ਕਰਦੀ ਹੈ:
- ਸਮੱਗਰੀ ਦਾ ਸਰੋਤ ਅਤੇ ਉਸ ਨਾਲ ਜੁੜੀਆਂ ਸ਼ਰਤਾਂ।
- ਹਰ ਕੀਤੀ ਕਾਰਵਾਈ: ਭੇਜਣਾ, ਸੰਭਾਲਣਾ, ਸੋਧਣਾ, ਪੇਸ਼ ਕਰਨਾ।
- ਹਰ ਵਸਤੂ ਸ਼੍ਰੇਣੀ ਲਈ ਸੰਭਾਲ, ਘੰਟਿਆਂ ਜਾਂ ਦਿਨਾਂ ਵਿੱਚ।
- ਪੇਸ਼ ਕਰਨ ਵਾਲੇ ਕਦਮ ਲਈ ਆਧਾਰ ਬਣੀ ਮਨਜ਼ੂਰੀ ਜਾਂ ਸੀਮਾ।
- ਹੱਕ ਧਾਰਕਾਂ ਲਈ ਸੰਪਰਕ ਅਤੇ ਹਟਾਉਣ ਦਾ ਰਾਹ।
ਸੂਚੀ ਨੂੰ ਆਰਕੀਟੈਕਚਰ ਚਿੱਤਰ ’ਤੇ ਨਹੀਂ, ਸਗੋਂ ਚੱਲ ਰਹੀ ਸੰਰਚਨਾ ’ਤੇ ਚਲਾਓ। ਜਿੱਥੇ ਜਵਾਬ ਨਹੀਂ ਹੈ, ਉਹੀ ਖੱਡਾ ਅਗਲਾ ਕੰਮ ਹੈ: ਜਾਂ ਤਾਂ ਉਸ ਕਾਰਵਾਈ ਲਈ ਮਨਜ਼ੂਰੀ ਲਵੋ, ਜਾਂ ਕਰਨਾ ਬੰਦ ਕਰੋ। ਵਪਾਰਕ ਸੇਵਾ ਲਈ, ਲਿਖਿਆ ਵਰਣਨ ਵਕੀਲ ਤੋਂ ਉਸ ਖੇਤਰ ਅਧਿਕਾਰ ਦੇ ਹਿਸਾਬ ਨਾਲ ਪੜ੍ਹਵਾਓ ਜਿੱਥੇ ਤੁਸੀਂ ਸੇਵਾ ਦਿੰਦੇ ਹੋ, ਕਿਉਂਕਿ ਉਹੀ ਵਰਣਨ ਇਹ ਸਮੀਖਿਆ ਸੰਭਵ ਬਣਾਉਂਦਾ ਹੈ। ਜੋ ਤੁਸੀਂ ਲਿਖਤੀ ਰੂਪ ਵਿੱਚ ਬਿਆਨ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਉਹ ਸਥਿਤੀ ਹੈ ਜਿਸਦਾ ਤੁਸੀਂ ਬਚਾਅ ਨਹੀਂ ਕਰ ਸਕਦੇ।