ਲੇਖਕ: ਸਰ ਟਿਮ ਬਰਨਰਸ-ਲੀ, URIs, URLs, HTTP, HTML ਅਤੇ ਵਰਲਡ ਵਾਈਡ ਵੈੱਬ ਦੇ ਖੋਜੀ, ਅਤੇ W3C ਦੇ ਮੌਜੂਦਾ ਮੁਖੀ। 1998 ਵਿੱਚ ਲਿਖਿਆ ਲੇਖ

ਕਿਸ URI ਨੂੰ "ਕੂਲ" ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ?
ਇੱਕ ਜੋ ਬਦਲਦਾ ਨਹੀਂ ਹੈ।
URI ਕਿਵੇਂ ਬਦਲੇ ਜਾਂਦੇ ਹਨ?
URI ਬਦਲਦੇ ਨਹੀਂ ਹਨ: ਲੋਕ ਉਹਨਾਂ ਨੂੰ ਬਦਲਦੇ ਹਨ।

ਸਿਧਾਂਤ ਵਿੱਚ, ਲੋਕਾਂ ਲਈ URI ਨੂੰ ਬਦਲਣ (ਜਾਂ ਸਹਾਇਕ ਦਸਤਾਵੇਜ਼ਾਂ ਨੂੰ ਬੰਦ ਕਰਨ) ਦਾ ਕੋਈ ਕਾਰਨ ਨਹੀਂ ਹੈ, ਪਰ ਅਭਿਆਸ ਵਿੱਚ ਉਹਨਾਂ ਦੀ ਗਿਣਤੀ ਲੱਖਾਂ ਹਨ।

ਸਿਧਾਂਤ ਵਿੱਚ, ਇੱਕ ਡੋਮੇਨ ਨੇਮਸਪੇਸ ਦਾ ਨਾਮਾਤਰ ਮਾਲਕ ਅਸਲ ਵਿੱਚ ਡੋਮੇਨ ਨੇਮਸਪੇਸ ਦਾ ਮਾਲਕ ਹੁੰਦਾ ਹੈ ਅਤੇ ਇਸਲਈ ਇਸਦੇ ਅੰਦਰ ਸਾਰੇ ਯੂ.ਆਰ.ਆਈ. ਦਿਵਾਲੀਆ ਹੋਣ ਤੋਂ ਇਲਾਵਾ, ਕੁਝ ਵੀ ਡੋਮੇਨ ਨਾਮ ਦੇ ਮਾਲਕ ਨੂੰ ਨਾਮ ਰੱਖਣ ਤੋਂ ਨਹੀਂ ਰੋਕਦਾ। ਅਤੇ ਸਿਧਾਂਤ ਵਿੱਚ, ਤੁਹਾਡੇ ਡੋਮੇਨ ਨਾਮ ਦੇ ਅਧੀਨ URI ਸਪੇਸ ਪੂਰੀ ਤਰ੍ਹਾਂ ਤੁਹਾਡੇ ਨਿਯੰਤਰਣ ਵਿੱਚ ਹੈ, ਇਸਲਈ ਤੁਸੀਂ ਇਸਨੂੰ ਆਪਣੀ ਮਰਜ਼ੀ ਅਨੁਸਾਰ ਸਥਿਰ ਬਣਾ ਸਕਦੇ ਹੋ। ਇੰਟਰਨੈਟ ਤੋਂ ਕਿਸੇ ਦਸਤਾਵੇਜ਼ ਦੇ ਗਾਇਬ ਹੋਣ ਦਾ ਬਹੁਤ ਹੀ ਵਧੀਆ ਕਾਰਨ ਇਹ ਹੈ ਕਿ ਡੋਮੇਨ ਨਾਮ ਦੀ ਮਾਲਕੀ ਵਾਲੀ ਕੰਪਨੀ ਕਾਰੋਬਾਰ ਤੋਂ ਬਾਹਰ ਹੋ ਗਈ ਹੈ ਜਾਂ ਸਰਵਰ ਨੂੰ ਚਾਲੂ ਰੱਖਣ ਦੀ ਸਮਰੱਥਾ ਨਹੀਂ ਰੱਖ ਸਕਦੀ। ਫਿਰ ਦੁਨੀਆਂ ਵਿੱਚ ਇੰਨੇ ਗੁੰਮ ਹੋਏ ਲਿੰਕ ਕਿਉਂ ਹਨ? ਇਸ ਵਿੱਚੋਂ ਕੁਝ ਸਿਰਫ਼ ਪੂਰਵ-ਵਿਚਾਰ ਦੀ ਘਾਟ ਹੈ। ਇੱਥੇ ਕੁਝ ਕਾਰਨ ਹਨ ਜੋ ਤੁਸੀਂ ਸੁਣ ਸਕਦੇ ਹੋ:

ਅਸੀਂ ਹੁਣੇ ਹੀ ਸਾਈਟ ਨੂੰ ਬਿਹਤਰ ਬਣਾਉਣ ਲਈ ਪੁਨਰਗਠਿਤ ਕੀਤਾ ਹੈ।

ਕੀ ਤੁਸੀਂ ਸੱਚਮੁੱਚ ਸੋਚਦੇ ਹੋ ਕਿ ਪੁਰਾਣੇ URI ਹੁਣ ਕੰਮ ਨਹੀਂ ਕਰ ਸਕਦੇ? ਜੇਕਰ ਅਜਿਹਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਉਹਨਾਂ ਨੂੰ ਬਹੁਤ ਮਾੜੀ ਢੰਗ ਨਾਲ ਚੁਣਿਆ ਹੈ। ਅਗਲੇ ਰੀਡਿਜ਼ਾਈਨ ਲਈ ਨਵੇਂ ਰੱਖਣ ਬਾਰੇ ਵਿਚਾਰ ਕਰੋ।

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

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

ਖੈਰ, ਅਸੀਂ ਖੋਜ ਕੀਤੀ ਕਿ ਸਾਨੂੰ ਫਾਈਲਾਂ ਨੂੰ ਮੂਵ ਕਰਨ ਦੀ ਲੋੜ ਹੈ...

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

ਜੌਨ ਹੁਣ ਇਸ ਫਾਈਲ ਨੂੰ ਸੰਭਾਲਦਾ ਨਹੀਂ ਹੈ, ਜੇਨ ਹੁਣ ਕਰਦੀ ਹੈ।

ਕੀ ਯੂਆਰਆਈ ਵਿੱਚ ਜੌਨ ਦਾ ਨਾਮ ਸੀ? ਨਹੀਂ, ਕੀ ਫਾਈਲ ਸਿਰਫ ਉਸਦੀ ਡਾਇਰੈਕਟਰੀ ਵਿੱਚ ਸੀ? ਠੀਕ ਹੈ, ਠੀਕ ਹੈ।

ਪਹਿਲਾਂ ਅਸੀਂ ਇਸਦੇ ਲਈ ਇੱਕ CGI ਸਕ੍ਰਿਪਟ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸੀ, ਪਰ ਹੁਣ ਅਸੀਂ ਇੱਕ ਬਾਈਨਰੀ ਪ੍ਰੋਗਰਾਮ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ।

ਇੱਕ ਪਾਗਲ ਵਿਚਾਰ ਹੈ ਕਿ ਸਕ੍ਰਿਪਟਾਂ ਦੁਆਰਾ ਬਣਾਏ ਗਏ ਪੰਨੇ "cgibin" ਜਾਂ "cgi" ਖੇਤਰ ਵਿੱਚ ਸਥਿਤ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ. ਇਹ ਤੁਹਾਡੇ ਵੈਬ ਸਰਵਰ ਨੂੰ ਚਲਾਉਣ ਦੇ ਮਕੈਨਿਕਸ ਨੂੰ ਉਜਾਗਰ ਕਰਦਾ ਹੈ। ਤੁਸੀਂ ਵਿਧੀ ਨੂੰ ਬਦਲਦੇ ਹੋ (ਸਮੱਗਰੀ ਨੂੰ ਸੁਰੱਖਿਅਤ ਕਰਦੇ ਹੋਏ ਵੀ), ਅਤੇ ਓਹੋ - ਤੁਹਾਡੇ ਸਾਰੇ URI ਬਦਲਦੇ ਹਨ.

ਉਦਾਹਰਨ ਲਈ ਨੈਸ਼ਨਲ ਸਾਇੰਸ ਫਾਊਂਡੇਸ਼ਨ (NSF) ਨੂੰ ਲਓ:

NSF ਔਨਲਾਈਨ ਦਸਤਾਵੇਜ਼

http://www.nsf.gov/cgi-bin/pubsys/browser/odbrowse.pl

ਦਸਤਾਵੇਜ਼ਾਂ ਨੂੰ ਦੇਖਣਾ ਸ਼ੁਰੂ ਕਰਨ ਵਾਲਾ ਪਹਿਲਾ ਪੰਨਾ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਕੁਝ ਸਾਲਾਂ ਵਿੱਚ ਇੱਕੋ ਜਿਹਾ ਨਹੀਂ ਰਹੇਗਾ। cgi-bin, oldbrowse и pl - ਇਹ ਸਭ ਕੁਝ ਇਸ ਬਾਰੇ ਜਾਣਕਾਰੀ ਦਿੰਦਾ ਹੈ ਕਿ ਅਸੀਂ ਹੁਣ ਕਿਵੇਂ-ਕਰਦੇ ਹਾਂ। ਜੇਕਰ ਤੁਸੀਂ ਕਿਸੇ ਦਸਤਾਵੇਜ਼ ਦੀ ਖੋਜ ਕਰਨ ਲਈ ਪੰਨੇ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਨੂੰ ਮਿਲਣ ਵਾਲਾ ਪਹਿਲਾ ਨਤੀਜਾ ਵੀ ਬਰਾਬਰ ਮਾੜਾ ਹੈ:

ਕ੍ਰਿਪਟੋਲੋਜੀ ਅਤੇ ਕੋਡਿੰਗ ਥਿਊਰੀ 'ਤੇ ਵਰਕਿੰਗ ਗਰੁੱਪ ਦੀ ਰਿਪੋਰਟ

http://www.nsf.gov/cgi-bin/getpub?nsf9814

ਦਸਤਾਵੇਜ਼ ਸੂਚਕਾਂਕ ਪੰਨੇ ਲਈ, ਹਾਲਾਂਕਿ html ਦਸਤਾਵੇਜ਼ ਆਪਣੇ ਆਪ ਵਿੱਚ ਬਹੁਤ ਵਧੀਆ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ:

http://www.nsf.gov/pubs/1998/nsf9814/nsf9814.htm

ਇੱਥੇ pubs/1998 ਸਿਰਲੇਖ ਕਿਸੇ ਵੀ ਭਵਿੱਖੀ ਪੁਰਾਲੇਖ ਸੇਵਾ ਨੂੰ ਇੱਕ ਚੰਗਾ ਸੰਕੇਤ ਦੇਵੇਗਾ ਕਿ ਪੁਰਾਣੀ 1998 ਦਸਤਾਵੇਜ਼ ਵਰਗੀਕਰਣ ਸਕੀਮ ਲਾਗੂ ਹੈ। ਹਾਲਾਂਕਿ ਦਸਤਾਵੇਜ਼ ਨੰਬਰ 2098 ਵਿੱਚ ਵੱਖਰੇ ਦਿਖਾਈ ਦੇ ਸਕਦੇ ਹਨ, ਮੈਂ ਕਲਪਨਾ ਕਰਾਂਗਾ ਕਿ ਇਹ URI ਅਜੇ ਵੀ ਵੈਧ ਰਹੇਗਾ ਅਤੇ NSF ਜਾਂ ਕਿਸੇ ਹੋਰ ਸੰਸਥਾ ਵਿੱਚ ਦਖਲ ਨਹੀਂ ਦੇਵੇਗਾ ਜੋ ਪੁਰਾਲੇਖ ਨੂੰ ਬਣਾਈ ਰੱਖੇਗਾ।

ਮੈਨੂੰ ਨਹੀਂ ਲਗਦਾ ਸੀ ਕਿ URL ਨੂੰ ਨਿਰੰਤਰ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ - ਉੱਥੇ URNs ਸਨ.

ਇਹ ਸ਼ਾਇਦ ਯੂਆਰਐਨ ਬਹਿਸ ਦੇ ਸਭ ਤੋਂ ਮਾੜੇ ਪ੍ਰਭਾਵਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ. ਕੁਝ ਲੋਕ ਸੋਚਦੇ ਹਨ ਕਿ ਵਧੇਰੇ ਸਥਾਈ ਨੇਮਸਪੇਸ ਵਿੱਚ ਖੋਜ ਦੇ ਕਾਰਨ, ਉਹ ਲਟਕਣ ਵਾਲੇ ਲਿੰਕਾਂ ਬਾਰੇ ਲਾਪਰਵਾਹ ਹੋ ਸਕਦੇ ਹਨ ਕਿਉਂਕਿ "URN ਸਭ ਕੁਝ ਠੀਕ ਕਰ ਦੇਵੇਗਾ।" ਜੇਕਰ ਤੁਸੀਂ ਇਹਨਾਂ ਲੋਕਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹੋ, ਤਾਂ ਮੈਨੂੰ ਤੁਹਾਨੂੰ ਨਿਰਾਸ਼ ਕਰਨ ਦਿਓ।

ਜ਼ਿਆਦਾਤਰ URN ਸਕੀਮਾਂ ਜੋ ਮੈਂ ਦੇਖੀਆਂ ਹਨ ਉਹ ਇੱਕ ਅਥਾਰਟੀ ਆਈਡੈਂਟੀਫਾਇਰ ਵਾਂਗ ਦਿਖਾਈ ਦਿੰਦੀਆਂ ਹਨ ਜਾਂ ਤਾਂ ਤੁਹਾਡੇ ਦੁਆਰਾ ਚੁਣੀ ਗਈ ਇੱਕ ਮਿਤੀ ਅਤੇ ਇੱਕ ਸਤਰ, ਜਾਂ ਸਿਰਫ਼ ਇੱਕ ਸਤਰ ਜੋ ਤੁਸੀਂ ਚੁਣਦੇ ਹੋ। ਇਹ ਇੱਕ HTTP URI ਦੇ ਸਮਾਨ ਹੈ। ਦੂਜੇ ਸ਼ਬਦਾਂ ਵਿੱਚ, ਜੇ ਤੁਸੀਂ ਸੋਚਦੇ ਹੋ ਕਿ ਤੁਹਾਡੀ ਸੰਸਥਾ ਲੰਬੇ ਸਮੇਂ ਤੱਕ ਚੱਲਣ ਵਾਲੇ URN ਬਣਾਉਣ ਦੇ ਯੋਗ ਹੋਵੇਗੀ, ਤਾਂ ਆਪਣੇ HTTP URIs ਲਈ ਉਹਨਾਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਹੁਣੇ ਸਾਬਤ ਕਰੋ। HTTP ਵਿੱਚ ਅਜਿਹਾ ਕੁਝ ਵੀ ਨਹੀਂ ਹੈ ਜੋ ਤੁਹਾਡੇ URI ਨੂੰ ਅਸਥਿਰ ਬਣਾਉਂਦਾ ਹੈ। ਸਿਰਫ਼ ਤੁਹਾਡੀ ਸੰਸਥਾ। ਇੱਕ ਡੇਟਾਬੇਸ ਬਣਾਓ ਜੋ ਦਸਤਾਵੇਜ਼ URN ਨੂੰ ਮੌਜੂਦਾ ਫਾਈਲ ਨਾਮ ਨਾਲ ਮੈਪ ਕਰਦਾ ਹੈ, ਅਤੇ ਵੈਬ ਸਰਵਰ ਨੂੰ ਅਸਲ ਵਿੱਚ ਫਾਈਲਾਂ ਨੂੰ ਮੁੜ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਇਸਦੀ ਵਰਤੋਂ ਕਰਨ ਦਿਓ।

ਜੇਕਰ ਤੁਸੀਂ ਇਸ ਮੁਕਾਮ 'ਤੇ ਪਹੁੰਚ ਗਏ ਹੋ, ਜੇਕਰ ਤੁਹਾਡੇ ਕੋਲ ਕੁਝ ਸੌਫਟਵੇਅਰ ਵਿਕਸਿਤ ਕਰਨ ਲਈ ਸਮਾਂ, ਪੈਸਾ ਅਤੇ ਕੁਨੈਕਸ਼ਨ ਨਹੀਂ ਹਨ, ਤਾਂ ਤੁਸੀਂ ਹੇਠਾਂ ਦਿੱਤੇ ਬਹਾਨੇ ਦੱਸ ਸਕਦੇ ਹੋ:

ਅਸੀਂ ਚਾਹੁੰਦੇ ਸੀ, ਪਰ ਸਾਡੇ ਕੋਲ ਸਹੀ ਸਾਧਨ ਨਹੀਂ ਹਨ।

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

ਤੁਹਾਨੂੰ URI ਨੂੰ ਬਦਲੇ ਬਿਨਾਂ URI ਸਪੇਸ ਵਿੱਚ ਮਲਕੀਅਤ, ਦਸਤਾਵੇਜ਼ ਪਹੁੰਚ, ਪੁਰਾਲੇਖ ਪੱਧਰ ਦੀ ਸੁਰੱਖਿਆ, ਆਦਿ ਨੂੰ ਬਦਲਣ ਦੇ ਯੋਗ ਹੋਣ ਦੀ ਲੋੜ ਹੈ।

ਇਹ ਸਭ ਬਹੁਤ ਬੁਰਾ ਹੈ। ਪਰ ਅਸੀਂ ਸਥਿਤੀ ਨੂੰ ਠੀਕ ਕਰਾਂਗੇ। W3C 'ਤੇ, ਅਸੀਂ Jigedit (Jigsaw ਸੰਪਾਦਨ ਸਰਵਰ) ਕਾਰਜਕੁਸ਼ਲਤਾ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ ਜੋ ਸੰਸਕਰਣਾਂ ਨੂੰ ਟਰੈਕ ਕਰਦੀ ਹੈ, ਅਤੇ ਅਸੀਂ ਦਸਤਾਵੇਜ਼ ਬਣਾਉਣ ਵਾਲੀਆਂ ਸਕ੍ਰਿਪਟਾਂ ਨਾਲ ਪ੍ਰਯੋਗ ਕਰਦੇ ਹਾਂ। ਜੇ ਤੁਸੀਂ ਟੂਲ, ਸਰਵਰ ਅਤੇ ਕਲਾਇੰਟਸ ਵਿਕਸਿਤ ਕਰਦੇ ਹੋ, ਤਾਂ ਇਸ ਸਮੱਸਿਆ ਵੱਲ ਧਿਆਨ ਦਿਓ!

ਇਹ ਬਹਾਨਾ ਬਹੁਤ ਸਾਰੇ W3C ਪੰਨਿਆਂ 'ਤੇ ਵੀ ਲਾਗੂ ਹੁੰਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ ਇਹ ਵੀ ਸ਼ਾਮਲ ਹੈ: ਇਸ ਤਰ੍ਹਾਂ ਕਰੋ ਜਿਵੇਂ ਮੈਂ ਕਹਿੰਦਾ ਹਾਂ, ਨਾ ਕਿ ਜਿਵੇਂ ਮੈਂ ਕਰਦਾ ਹਾਂ।

ਮੈਨੂੰ ਪਰਵਾਹ ਕਿਉਂ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ?

ਜਦੋਂ ਤੁਸੀਂ ਆਪਣੇ ਸਰਵਰ 'ਤੇ URI ਬਦਲਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਕਦੇ ਵੀ ਪੂਰੀ ਤਰ੍ਹਾਂ ਇਹ ਨਹੀਂ ਦੱਸ ਸਕਦੇ ਹੋ ਕਿ ਪੁਰਾਣੇ URI ਨਾਲ ਕਿਸ ਕੋਲ ਲਿੰਕ ਹੋਣਗੇ। ਇਹ ਨਿਯਮਤ ਵੈੱਬ ਪੰਨਿਆਂ ਤੋਂ ਲਿੰਕ ਹੋ ਸਕਦੇ ਹਨ। ਆਪਣੇ ਪੰਨੇ ਨੂੰ ਬੁੱਕਮਾਰਕ ਕਰੋ। ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਯੂਆਰਆਈ ਕਿਸੇ ਦੋਸਤ ਨੂੰ ਲਿਖੀ ਚਿੱਠੀ ਦੇ ਹਾਸ਼ੀਏ ਵਿੱਚ ਸਕ੍ਰੌਲ ਕੀਤਾ ਗਿਆ ਹੋਵੇ।

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

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

ਤਾਂ ਮੈਨੂੰ ਕੀ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ? URI ਡਿਜ਼ਾਈਨ

ਇਹ ਵੈਬਮਾਸਟਰ ਦੀ ਜਿੰਮੇਵਾਰੀ ਹੈ ਕਿ ਉਹ ਯੂਆਰਆਈ ਨਿਰਧਾਰਤ ਕਰੇ ਜੋ 2 ਸਾਲਾਂ ਵਿੱਚ, 20 ਸਾਲਾਂ ਵਿੱਚ, 200 ਸਾਲਾਂ ਵਿੱਚ ਵਰਤੇ ਜਾ ਸਕਦੇ ਹਨ। ਇਸ ਲਈ ਸੋਚ, ਸੰਗਠਨ ਅਤੇ ਦ੍ਰਿੜਤਾ ਦੀ ਲੋੜ ਹੈ।

URI ਬਦਲ ਜਾਂਦੇ ਹਨ ਜੇਕਰ ਉਹਨਾਂ ਵਿੱਚ ਕੋਈ ਜਾਣਕਾਰੀ ਬਦਲ ਜਾਂਦੀ ਹੈ। ਤੁਸੀਂ ਉਹਨਾਂ ਨੂੰ ਕਿਵੇਂ ਡਿਜ਼ਾਈਨ ਕਰਦੇ ਹੋ ਇਹ ਬਹੁਤ ਮਹੱਤਵਪੂਰਨ ਹੈ। (ਕੀ, URI ਡਿਜ਼ਾਈਨ? ਕੀ ਮੈਨੂੰ URI ਡਿਜ਼ਾਈਨ ਕਰਨ ਦੀ ਲੋੜ ਹੈ? ਹਾਂ, ਤੁਹਾਨੂੰ ਇਸ ਬਾਰੇ ਸੋਚਣਾ ਚਾਹੀਦਾ ਹੈ)। ਡਿਜ਼ਾਈਨ ਦਾ ਮੂਲ ਰੂਪ ਵਿੱਚ ਅਰਥ ਹੈ URI ਵਿੱਚ ਕਿਸੇ ਵੀ ਜਾਣਕਾਰੀ ਨੂੰ ਛੱਡਣਾ।

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

ਸਿਰਫ ਅਪਵਾਦ ਇੱਕ ਪੰਨਾ ਹੈ ਜੋ ਜਾਣਬੁੱਝ ਕੇ "ਨਵੀਨਤਮ" ਸੰਸਕਰਣ ਹੈ, ਉਦਾਹਰਨ ਲਈ ਪੂਰੀ ਸੰਸਥਾ ਜਾਂ ਇਸਦੇ ਵੱਡੇ ਹਿੱਸੇ ਲਈ।

http://www.pathfinder.com/money/moneydaily/latest/

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

http://www.pathfinder.com/money/moneydaily/1998/981212.moneyonline.html

(ਚੰਗਾ ਲੱਗ ਰਿਹਾ ਹੈ। ਇਹ ਮੰਨਦਾ ਹੈ ਕਿ pathfinder.com ਦੀ ਸਾਰੀ ਉਮਰ ਵਿੱਚ "ਪੈਸਾ" ਦਾ ਮਤਲਬ ਇੱਕੋ ਹੀ ਹੋਵੇਗਾ। ਇੱਥੇ ਇੱਕ ਡੁਪਲੀਕੇਟ "98" ਅਤੇ ਇੱਕ ਬੇਲੋੜਾ ".html" ਹੈ, ਪਰ ਨਹੀਂ ਤਾਂ ਇੱਕ ਮਜ਼ਬੂਤ ​​URI ਵਾਂਗ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ।

ਇੱਕ ਪਾਸੇ ਕੀ ਛੱਡਣਾ ਹੈ

ਸਾਰੇ! ਬਣਾਉਣ ਦੀ ਮਿਤੀ ਤੋਂ ਇਲਾਵਾ, URI ਵਿੱਚ ਕੋਈ ਵੀ ਜਾਣਕਾਰੀ ਪਾਉਣਾ ਇੱਕ ਜਾਂ ਦੂਜੇ ਤਰੀਕੇ ਨਾਲ ਸਮੱਸਿਆ ਲਈ ਪੁੱਛ ਰਿਹਾ ਹੈ।

• ਲੇਖਕ ਦਾ ਨਾਮ. ਨਵੇਂ ਸੰਸਕਰਣ ਉਪਲਬਧ ਹੋਣ 'ਤੇ ਲੇਖਕਤਾ ਬਦਲ ਸਕਦੀ ਹੈ। ਲੋਕ ਸੰਗਠਨਾਂ ਨੂੰ ਛੱਡ ਦਿੰਦੇ ਹਨ ਅਤੇ ਚੀਜ਼ਾਂ ਨੂੰ ਦੂਜਿਆਂ ਤੱਕ ਪਹੁੰਚਾਉਂਦੇ ਹਨ.
• ਵਿਸ਼ਾ. ਇਹ ਬਹੁਤ ਔਖਾ ਹੈ। ਇਹ ਹਮੇਸ਼ਾ ਪਹਿਲਾਂ ਵਧੀਆ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ, ਪਰ ਹੈਰਾਨੀਜਨਕ ਤੌਰ 'ਤੇ ਤੇਜ਼ੀ ਨਾਲ ਬਦਲਦਾ ਹੈ। ਮੈਂ ਹੇਠਾਂ ਇਸ ਬਾਰੇ ਹੋਰ ਗੱਲ ਕਰਾਂਗਾ।
• ਸਥਿਤੀ. "ਪੁਰਾਣੀ", "ਡਰਾਫਟ" ਅਤੇ ਇਸ ਤਰ੍ਹਾਂ ਦੀਆਂ ਡਾਇਰੈਕਟਰੀਆਂ, "ਨਵੀਨਤਮ" ਅਤੇ "ਕੂਲ" ਦਾ ਜ਼ਿਕਰ ਨਾ ਕਰਨ ਲਈ, ਸਾਰੇ ਫਾਈਲ ਸਿਸਟਮਾਂ ਵਿੱਚ ਦਿਖਾਈ ਦਿੰਦੀਆਂ ਹਨ। ਦਸਤਾਵੇਜ਼ ਸਥਿਤੀ ਨੂੰ ਬਦਲਦੇ ਹਨ - ਨਹੀਂ ਤਾਂ ਡਰਾਫਟ ਬਣਾਉਣ ਦਾ ਕੋਈ ਮਤਲਬ ਨਹੀਂ ਹੋਵੇਗਾ। ਇੱਕ ਦਸਤਾਵੇਜ਼ ਦੇ ਨਵੀਨਤਮ ਸੰਸਕਰਣ ਨੂੰ ਇੱਕ ਸਥਾਈ ਪਛਾਣਕਰਤਾ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਭਾਵੇਂ ਇਸਦੀ ਸਥਿਤੀ ਜੋ ਵੀ ਹੋਵੇ। ਸਟੇਟਸ ਨੂੰ ਨਾਮ ਤੋਂ ਦੂਰ ਰੱਖੋ।
• ਪਹੁੰਚ. W3C 'ਤੇ, ਅਸੀਂ ਸਾਈਟ ਨੂੰ ਸਟਾਫ, ਮੈਂਬਰਾਂ ਅਤੇ ਜਨਤਾ ਲਈ ਭਾਗਾਂ ਵਿੱਚ ਵੰਡਿਆ ਹੈ। ਇਹ ਚੰਗਾ ਲੱਗਦਾ ਹੈ, ਪਰ ਬੇਸ਼ੱਕ, ਦਸਤਾਵੇਜ਼ ਕਰਮਚਾਰੀਆਂ ਤੋਂ ਟੀਮ ਦੇ ਵਿਚਾਰਾਂ ਵਜੋਂ ਸ਼ੁਰੂ ਹੁੰਦੇ ਹਨ, ਮੈਂਬਰਾਂ ਨਾਲ ਚਰਚਾ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਫਿਰ ਜਨਤਕ ਗਿਆਨ ਬਣ ਜਾਂਦੇ ਹਨ। ਇਹ ਸੱਚਮੁੱਚ ਸ਼ਰਮ ਦੀ ਗੱਲ ਹੋਵੇਗੀ ਜੇਕਰ ਹਰ ਵਾਰ ਇੱਕ ਦਸਤਾਵੇਜ਼ ਨੂੰ ਵਿਆਪਕ ਚਰਚਾ ਲਈ ਖੋਲ੍ਹਿਆ ਜਾਂਦਾ ਹੈ, ਉਸ ਦੇ ਸਾਰੇ ਪੁਰਾਣੇ ਲਿੰਕ ਟੁੱਟ ਜਾਂਦੇ ਹਨ! ਹੁਣ ਅਸੀਂ ਇੱਕ ਸਧਾਰਨ ਮਿਤੀ ਕੋਡ ਵੱਲ ਵਧਦੇ ਹਾਂ।
• ਫਾਈਲ ਐਕਸਟੈਂਸ਼ਨ. ਇੱਕ ਬਹੁਤ ਹੀ ਆਮ ਵਰਤਾਰੇ. "cgi", ਇੱਥੋਂ ਤੱਕ ਕਿ ".html" ਭਵਿੱਖ ਵਿੱਚ ਬਦਲ ਜਾਵੇਗਾ। ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਤੁਸੀਂ 20 ਸਾਲਾਂ ਵਿੱਚ ਇਸ ਪੰਨੇ ਲਈ HTML ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕਰ ਰਹੇ ਹੋ, ਪਰ ਇਸਦੇ ਲਈ ਅੱਜ ਦੇ ਲਿੰਕ ਅਜੇ ਵੀ ਕੰਮ ਕਰਨਗੇ। W3C ਸਾਈਟ 'ਤੇ ਕੈਨੋਨੀਕਲ ਲਿੰਕ ਐਕਸਟੈਂਸ਼ਨ ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕਰਦੇ (ਇਹ ਕਿਵੇਂ ਕੀਤਾ ਗਿਆ ਹੈ).
• ਸਾਫਟਵੇਅਰ ਵਿਧੀ. URI ਵਿੱਚ, "cgi", "exec" ਅਤੇ ਹੋਰ ਸ਼ਬਦਾਂ ਦੀ ਖੋਜ ਕਰੋ ਜੋ ਚੀਕਦੇ ਹਨ "ਦੇਖੋ ਅਸੀਂ ਕਿਹੜਾ ਸੌਫਟਵੇਅਰ ਵਰਤ ਰਹੇ ਹਾਂ।" ਕੀ ਕੋਈ ਆਪਣੀ ਪੂਰੀ ਜ਼ਿੰਦਗੀ ਪਰਲ ਸੀਜੀਆਈ ਸਕ੍ਰਿਪਟਾਂ ਲਿਖਣ ਵਿੱਚ ਬਿਤਾਉਣਾ ਚਾਹੁੰਦਾ ਹੈ? ਨਹੀਂ? ਫਿਰ .pl ਐਕਸਟੈਂਸ਼ਨ ਨੂੰ ਹਟਾਓ। ਇਹ ਕਿਵੇਂ ਕਰਨਾ ਹੈ ਇਸ ਬਾਰੇ ਸਰਵਰ ਮੈਨੂਅਲ ਪੜ੍ਹੋ।
• ਡਿਸਕ ਦਾ ਨਾਮ। ਆ ਜਾਓ! ਪਰ ਮੈਂ ਇਹ ਦੇਖਿਆ ਹੈ।

ਇਸ ਲਈ ਸਾਡੀ ਸਾਈਟ ਤੋਂ ਸਭ ਤੋਂ ਵਧੀਆ ਉਦਾਹਰਣ ਹੈ

http://www.w3.org/1998/12/01/chairs

... W3C ਚੇਅਰਜ਼ ਮੀਟਿੰਗ ਦੇ ਮਿੰਟਾਂ 'ਤੇ ਰਿਪੋਰਟ.

ਵਿਸ਼ੇ ਦੁਆਰਾ ਵਿਸ਼ੇ ਅਤੇ ਵਰਗੀਕਰਨ

ਮੈਂ ਇਸ ਖ਼ਤਰੇ ਬਾਰੇ ਵਧੇਰੇ ਵਿਸਥਾਰ ਵਿੱਚ ਜਾਵਾਂਗਾ, ਕਿਉਂਕਿ ਇਹ ਉਹਨਾਂ ਚੀਜ਼ਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ ਜਿਸ ਤੋਂ ਬਚਣਾ ਸਭ ਤੋਂ ਮੁਸ਼ਕਲ ਹੈ। ਆਮ ਤੌਰ 'ਤੇ, ਵਿਸ਼ੇ URIs ਵਿੱਚ ਖਤਮ ਹੁੰਦੇ ਹਨ ਜਦੋਂ ਤੁਸੀਂ ਆਪਣੇ ਦਸਤਾਵੇਜ਼ਾਂ ਨੂੰ ਉਹਨਾਂ ਦੁਆਰਾ ਕੀਤੇ ਗਏ ਕੰਮ ਦੁਆਰਾ ਸ਼੍ਰੇਣੀਬੱਧ ਕਰਦੇ ਹੋ। ਪਰ ਇਹ ਟੁੱਟ-ਭੱਜ ਸਮੇਂ ਦੇ ਨਾਲ ਬਦਲ ਜਾਵੇਗੀ। ਖੇਤਰਾਂ ਦੇ ਨਾਮ ਬਦਲ ਜਾਣਗੇ। W3C 'ਤੇ ਅਸੀਂ ਸੈਕਸ਼ਨ ਦੀ ਅਸਲ ਸਮੱਗਰੀ ਨੂੰ ਦਰਸਾਉਣ ਲਈ MarkUP ਨੂੰ ਮਾਰਕਅੱਪ ਅਤੇ ਫਿਰ HTML ਵਿੱਚ ਬਦਲਣਾ ਚਾਹੁੰਦੇ ਸੀ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਅਕਸਰ ਇੱਕ ਫਲੈਟ ਨੇਮਸਪੇਸ ਹੁੰਦਾ ਹੈ। 100 ਸਾਲਾਂ ਵਿੱਚ, ਕੀ ਤੁਹਾਨੂੰ ਯਕੀਨ ਹੈ ਕਿ ਤੁਸੀਂ ਕੁਝ ਵੀ ਦੁਬਾਰਾ ਨਹੀਂ ਵਰਤਣਾ ਚਾਹੋਗੇ? ਸਾਡੇ ਛੋਟੇ ਜੀਵਨ ਵਿੱਚ ਅਸੀਂ ਪਹਿਲਾਂ ਹੀ ਉਦਾਹਰਨ ਲਈ "ਇਤਿਹਾਸ" ਅਤੇ "ਸ਼ੈਲੀ ਸ਼ੀਟਾਂ" ਦੀ ਮੁੜ ਵਰਤੋਂ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹਾਂ।

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

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

ਵਾਸਤਵ ਵਿੱਚ, ਜਦੋਂ ਤੁਸੀਂ ਇੱਕ URI ਵਿੱਚ ਵਿਸ਼ੇ ਦੇ ਨਾਮ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਆਪਣੇ ਆਪ ਨੂੰ ਕਿਸੇ ਕਿਸਮ ਦੇ ਵਰਗੀਕਰਨ ਲਈ ਵਚਨਬੱਧ ਕਰ ਰਹੇ ਹੋ। ਸ਼ਾਇਦ ਭਵਿੱਖ ਵਿੱਚ ਤੁਸੀਂ ਇੱਕ ਵੱਖਰੇ ਵਿਕਲਪ ਨੂੰ ਤਰਜੀਹ ਦਿਓਗੇ. URI ਫਿਰ ਉਲੰਘਣਾ ਲਈ ਸੰਵੇਦਨਸ਼ੀਲ ਹੋਵੇਗਾ।

URI ਦੇ ਹਿੱਸੇ ਵਜੋਂ ਵਿਸ਼ਾ ਖੇਤਰ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦਾ ਕਾਰਨ ਇਹ ਹੈ ਕਿ URI ਸਪੇਸ ਦੇ ਉਪ-ਭਾਗਾਂ ਦੀ ਜ਼ਿੰਮੇਵਾਰੀ ਆਮ ਤੌਰ 'ਤੇ ਸੌਂਪੀ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਫਿਰ ਤੁਹਾਨੂੰ ਸੰਗਠਨਾਤਮਕ ਸੰਸਥਾ ਦੇ ਨਾਮ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ - ਵਿਭਾਗ, ਸਮੂਹ, ਜਾਂ ਜੋ ਵੀ - ਜੋ ਉਸ ਸਬਸਪੇਸ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹੈ। ਇਹ ਇੱਕ ਸੰਗਠਨਾਤਮਕ ਢਾਂਚੇ ਲਈ ਬਾਈਡਿੰਗ ਇੱਕ URI ਹੈ। ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਸਿਰਫ਼ ਉਦੋਂ ਹੀ ਸੁਰੱਖਿਅਤ ਹੁੰਦਾ ਹੈ ਜੇਕਰ ਅੱਗੇ (ਖੱਬੇ) URI ਨੂੰ ਇੱਕ ਮਿਤੀ ਦੁਆਰਾ ਸੁਰੱਖਿਅਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ: 1998/pics ਤੁਹਾਡੇ ਸਰਵਰ ਲਈ "ਸਾਡਾ 1998 ਵਿੱਚ ਤਸਵੀਰਾਂ ਨਾਲ ਕੀ ਮਤਲਬ ਸੀ" ਦਾ ਮਤਲਬ ਹੋ ਸਕਦਾ ਹੈ, ਨਾ ਕਿ "1998 ਵਿੱਚ ਅਸੀਂ ਉਸ ਨਾਲ ਕੀ ਕੀਤਾ ਜਿਸਨੂੰ ਅਸੀਂ ਹੁਣ ਤਸਵੀਰਾਂ ਕਹਿੰਦੇ ਹਾਂ।"

ਡੋਮੇਨ ਨਾਮ ਨੂੰ ਨਾ ਭੁੱਲੋ

ਯਾਦ ਰੱਖੋ ਕਿ ਇਹ ਨਾ ਸਿਰਫ਼ URI ਵਿੱਚ ਮਾਰਗ 'ਤੇ ਲਾਗੂ ਹੁੰਦਾ ਹੈ, ਸਗੋਂ ਸਰਵਰ ਨਾਮ 'ਤੇ ਵੀ ਲਾਗੂ ਹੁੰਦਾ ਹੈ। ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਵੱਖ-ਵੱਖ ਚੀਜ਼ਾਂ ਲਈ ਵੱਖਰੇ ਸਰਵਰ ਹਨ, ਤਾਂ ਯਾਦ ਰੱਖੋ ਕਿ ਇਹ ਵਿਭਾਜਨ ਬਹੁਤ ਸਾਰੇ, ਬਹੁਤ ਸਾਰੇ ਲਿੰਕਾਂ ਨੂੰ ਨਸ਼ਟ ਕੀਤੇ ਬਿਨਾਂ ਬਦਲਣਾ ਅਸੰਭਵ ਹੋਵੇਗਾ. ਕੁਝ ਕਲਾਸਿਕ "ਸਾਫ਼ਟਵੇਅਰ ਨੂੰ ਦੇਖੋ ਜੋ ਅਸੀਂ ਅੱਜ ਵਰਤਦੇ ਹਾਂ" ਗਲਤੀਆਂ ਡੋਮੇਨ ਨਾਮ "cgi.pathfinder.com", "ਸੁਰੱਖਿਅਤ", "lists.w3.org" ਹਨ। ਉਹ ਸਰਵਰ ਪ੍ਰਸ਼ਾਸਨ ਨੂੰ ਆਸਾਨ ਬਣਾਉਣ ਲਈ ਤਿਆਰ ਕੀਤੇ ਗਏ ਹਨ। ਭਾਵੇਂ ਇੱਕ ਡੋਮੇਨ ਤੁਹਾਡੀ ਕੰਪਨੀ ਵਿੱਚ ਇੱਕ ਵੰਡ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ, ਇੱਕ ਦਸਤਾਵੇਜ਼ ਸਥਿਤੀ, ਇੱਕ ਪਹੁੰਚ ਪੱਧਰ, ਜਾਂ ਇੱਕ ਸੁਰੱਖਿਆ ਪੱਧਰ, ਬਹੁਤ ਸਾਰੇ ਦਸਤਾਵੇਜ਼ ਕਿਸਮਾਂ ਲਈ ਇੱਕ ਤੋਂ ਵੱਧ ਡੋਮੇਨ ਨਾਮ ਵਰਤਣ ਤੋਂ ਪਹਿਲਾਂ ਬਹੁਤ ਸਾਵਧਾਨ ਰਹੋ। ਯਾਦ ਰੱਖੋ ਕਿ ਤੁਸੀਂ ਰੀਡਾਇਰੈਕਸ਼ਨ ਅਤੇ ਪ੍ਰੌਕਸੀ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਇੱਕ ਸਿੰਗਲ ਦਿਸਣ ਵਾਲੇ ਵੈੱਬ ਸਰਵਰ ਦੇ ਅੰਦਰ ਕਈ ਵੈਬ ਸਰਵਰਾਂ ਨੂੰ ਲੁਕਾ ਸਕਦੇ ਹੋ।

ਓਹ, ਅਤੇ ਆਪਣੇ ਡੋਮੇਨ ਨਾਮ ਬਾਰੇ ਵੀ ਸੋਚੋ. ਜਦੋਂ ਤੁਸੀਂ ਉਤਪਾਦ ਲਾਈਨਾਂ ਨੂੰ ਬਦਲਦੇ ਹੋ ਅਤੇ ਸਾਬਣ ਬਣਾਉਣਾ ਬੰਦ ਕਰ ਦਿੰਦੇ ਹੋ ਤਾਂ ਤੁਹਾਨੂੰ soap.com ਵਜੋਂ ਜਾਣਿਆ ਨਹੀਂ ਜਾਣਾ ਚਾਹੀਦਾ (ਇਸ ਸਮੇਂ soap.com ਦਾ ਮਾਲਕ ਕੌਣ ਹੈ)।

ਸਿੱਟਾ

ਇੱਕ URI ਨੂੰ 2, 20, 200, ਜਾਂ ਇੱਥੋਂ ਤੱਕ ਕਿ 2000 ਸਾਲਾਂ ਲਈ ਸੁਰੱਖਿਅਤ ਕਰਨਾ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਇੰਨਾ ਆਸਾਨ ਨਹੀਂ ਹੈ ਜਿੰਨਾ ਇਹ ਲੱਗਦਾ ਹੈ। ਹਾਲਾਂਕਿ, ਸਾਰੇ ਇੰਟਰਨੈਟ ਤੇ, ਵੈਬਮਾਸਟਰ ਅਜਿਹੇ ਫੈਸਲੇ ਲੈ ਰਹੇ ਹਨ ਜੋ ਭਵਿੱਖ ਵਿੱਚ ਆਪਣੇ ਲਈ ਇਸ ਕੰਮ ਨੂੰ ਅਸਲ ਵਿੱਚ ਮੁਸ਼ਕਲ ਬਣਾ ਰਹੇ ਹਨ. ਅਕਸਰ ਇਹ ਇਸ ਲਈ ਹੁੰਦਾ ਹੈ ਕਿਉਂਕਿ ਉਹ ਸਾਧਨਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ ਜਿਨ੍ਹਾਂ ਦਾ ਕੰਮ ਸਿਰਫ ਇਸ ਸਮੇਂ ਸਭ ਤੋਂ ਵਧੀਆ ਸਾਈਟ ਨੂੰ ਪੇਸ਼ ਕਰਨਾ ਹੈ - ਅਤੇ ਕਿਸੇ ਨੇ ਇਹ ਮੁਲਾਂਕਣ ਨਹੀਂ ਕੀਤਾ ਹੈ ਕਿ ਜਦੋਂ ਸਭ ਕੁਝ ਬਦਲਦਾ ਹੈ ਤਾਂ ਲਿੰਕਾਂ ਦਾ ਕੀ ਹੋਵੇਗਾ. ਹਾਲਾਂਕਿ, ਇੱਥੇ ਬਿੰਦੂ ਇਹ ਹੈ ਕਿ ਬਹੁਤ ਸਾਰੀਆਂ, ਬਹੁਤ ਸਾਰੀਆਂ ਚੀਜ਼ਾਂ ਬਦਲ ਸਕਦੀਆਂ ਹਨ, ਅਤੇ ਤੁਹਾਡੇ URIs ਇੱਕੋ ਜਿਹੇ ਰਹਿ ਸਕਦੇ ਹਨ ਅਤੇ ਰਹਿਣੇ ਚਾਹੀਦੇ ਹਨ. ਇਹ ਉਦੋਂ ਹੀ ਸੰਭਵ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਇਸ ਬਾਰੇ ਸੋਚਦੇ ਹੋ ਕਿ ਤੁਸੀਂ ਉਹਨਾਂ ਨੂੰ ਕਿਵੇਂ ਬਣਾਉਂਦੇ ਹੋ।

ਇਹ ਵੀ ਵੇਖੋ:

• ਇਸੇ ਵਿਸ਼ੇ 'ਤੇ ਜੈਕਬ ਨੀਲਸਨ ਦਾ ਟਿਰਡ

ਵਾਧੇ

ਫਾਈਲ ਐਕਸਟੈਂਸ਼ਨਾਂ ਨੂੰ ਕਿਵੇਂ ਹਟਾਉਣਾ ਹੈ ...

... ਮੌਜੂਦਾ ਫਾਈਲ-ਆਧਾਰਿਤ ਵੈੱਬ ਸਰਵਰ ਵਿੱਚ ਇੱਕ URI ਤੋਂ?

ਜੇ ਤੁਸੀਂ ਅਪਾਚੇ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋ, ਉਦਾਹਰਨ ਲਈ, ਤੁਸੀਂ ਇਸ ਨੂੰ ਸਮੱਗਰੀ ਨਾਲ ਗੱਲਬਾਤ ਕਰਨ ਲਈ ਕੌਂਫਿਗਰ ਕਰ ਸਕਦੇ ਹੋ। ਫਾਈਲ ਐਕਸਟੈਂਸ਼ਨ (ਉਦਾਹਰਨ ਲਈ .png) ਨੂੰ ਇੱਕ ਫਾਈਲ ਵਿੱਚ ਸੁਰੱਖਿਅਤ ਕਰੋ (ਉਦਾਹਰਨ ਲਈ. mydog.png), ਪਰ ਤੁਸੀਂ ਇਸਦੇ ਬਿਨਾਂ ਕਿਸੇ ਵੈੱਬ ਸਰੋਤ ਨਾਲ ਲਿੰਕ ਕਰ ਸਕਦੇ ਹੋ। Apache ਫਿਰ ਉਸ ਨਾਮ ਅਤੇ ਕਿਸੇ ਵੀ ਐਕਸਟੈਂਸ਼ਨ ਵਾਲੀਆਂ ਸਾਰੀਆਂ ਫਾਈਲਾਂ ਲਈ ਡਾਇਰੈਕਟਰੀ ਦੀ ਜਾਂਚ ਕਰਦਾ ਹੈ, ਅਤੇ ਸੈੱਟ ਵਿੱਚੋਂ ਸਭ ਤੋਂ ਵਧੀਆ ਚੁਣ ਸਕਦਾ ਹੈ (ਉਦਾਹਰਨ ਲਈ, GIF ਅਤੇ PNG)। ਅਤੇ ਵੱਖ-ਵੱਖ ਡਾਇਰੈਕਟਰੀਆਂ ਵਿੱਚ ਵੱਖ-ਵੱਖ ਕਿਸਮਾਂ ਦੀਆਂ ਫਾਈਲਾਂ ਪਾਉਣ ਦੀ ਕੋਈ ਲੋੜ ਨਹੀਂ ਹੈ, ਅਸਲ ਵਿੱਚ ਸਮੱਗਰੀ ਮੇਲ ਖਾਂਦਾ ਕੰਮ ਨਹੀਂ ਕਰੇਗਾ ਜੇਕਰ ਤੁਸੀਂ ਅਜਿਹਾ ਕਰਦੇ ਹੋ।

• ਸਮੱਗਰੀ ਨਾਲ ਗੱਲਬਾਤ ਕਰਨ ਲਈ ਆਪਣੇ ਸਰਵਰ ਨੂੰ ਸੈਟ ਅਪ ਕਰੋ
• ਹਮੇਸ਼ਾ ਬਿਨਾਂ ਐਕਸਟੈਂਸ਼ਨ ਦੇ URIs ਨਾਲ ਲਿੰਕ ਕਰੋ

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

(ਵਾਸਤਵ ਵਿੱਚ, mydog, mydog.png и mydog.gif - ਵੈਧ ਵੈੱਬ ਸਰੋਤ, mydog ਇੱਕ ਯੂਨੀਵਰਸਲ ਸਮੱਗਰੀ ਕਿਸਮ ਦਾ ਸਰੋਤ ਹੈ, ਅਤੇ mydog.png и mydog.gif - ਇੱਕ ਖਾਸ ਸਮੱਗਰੀ ਕਿਸਮ ਦੇ ਸਰੋਤ)।

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

ਸ਼ਰਮ ਦਾ ਬੋਰਡ - ਕਹਾਣੀ 1: ਚੈਨਲ 7

1999 ਦੇ ਦੌਰਾਨ, ਮੈਂ ਪੰਨੇ 'ਤੇ ਬਰਫ਼ ਕਾਰਨ ਸਕੂਲ ਬੰਦ ਹੋਣ ਦਾ ਪਤਾ ਲਗਾਇਆ http://www.whdh.com/stormforce/closings.shtml. ਟੀਵੀ ਸਕ੍ਰੀਨ ਦੇ ਤਲ 'ਤੇ ਜਾਣਕਾਰੀ ਦੇ ਦਿਖਾਈ ਦੇਣ ਦੀ ਉਡੀਕ ਨਾ ਕਰੋ! ਮੈਂ ਇਸਨੂੰ ਆਪਣੇ ਹੋਮ ਪੇਜ ਤੋਂ ਲਿੰਕ ਕੀਤਾ ਹੈ। 2000 ਦਾ ਪਹਿਲਾ ਵੱਡਾ ਬਰਫੀਲਾ ਤੂਫਾਨ ਆਇਆ ਅਤੇ ਮੈਂ ਪੰਨਾ ਚੈੱਕ ਕੀਤਾ। ਉਥੇ ਲਿਖਿਆ ਹੈ:,

- ਦੇ ਤੌਰ 'ਤੇ.
ਫਿਲਹਾਲ ਕੁਝ ਵੀ ਬੰਦ ਨਹੀਂ ਹੈ। ਕਿਰਪਾ ਕਰਕੇ ਮੌਸਮ ਚੇਤਾਵਨੀਆਂ ਦੇ ਮਾਮਲੇ ਵਿੱਚ ਵਾਪਸ ਆਓ।

ਇਹ ਇੰਨਾ ਤੇਜ਼ ਤੂਫ਼ਾਨ ਨਹੀਂ ਹੋ ਸਕਦਾ। ਇਹ ਅਜੀਬ ਹੈ ਕਿ ਤਾਰੀਖ ਗੁੰਮ ਹੈ. ਪਰ ਜੇ ਤੁਸੀਂ ਸਾਈਟ ਦੇ ਮੁੱਖ ਪੰਨੇ 'ਤੇ ਜਾਂਦੇ ਹੋ, ਤਾਂ ਉੱਥੇ ਇੱਕ ਵੱਡਾ ਬਟਨ ਹੋਵੇਗਾ “ਬੰਦ ਸਕੂਲ”, ਜੋ ਪੰਨੇ ਵੱਲ ਲੈ ਜਾਂਦਾ ਹੈ। http://www.whdh.com/stormforce/ ਬੰਦ ਸਕੂਲਾਂ ਦੀ ਲੰਮੀ ਸੂਚੀ ਦੇ ਨਾਲ।

ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਉਹਨਾਂ ਨੇ ਸੂਚੀ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਸਿਸਟਮ ਬਦਲਿਆ - ਪਰ ਉਹਨਾਂ ਨੂੰ URI ਬਦਲਣ ਦੀ ਲੋੜ ਨਹੀਂ ਸੀ।

ਸ਼ਰਮ ਦਾ ਬੋਰਡ - ਕਹਾਣੀ 2: ਮਾਈਕ੍ਰੋਸਾੱਫਟ ਨੈੱਟਮੀਟਿੰਗ

ਇੰਟਰਨੈੱਟ 'ਤੇ ਵਧਦੀ ਨਿਰਭਰਤਾ ਦੇ ਨਾਲ, ਇੱਕ ਚਲਾਕ ਵਿਚਾਰ ਆਇਆ ਕਿ ਨਿਰਮਾਤਾ ਦੀ ਵੈੱਬਸਾਈਟ ਦੇ ਲਿੰਕ ਐਪਲੀਕੇਸ਼ਨਾਂ ਵਿੱਚ ਸ਼ਾਮਲ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ। ਇਸਦੀ ਬਹੁਤ ਵਰਤੋਂ ਅਤੇ ਦੁਰਵਿਵਹਾਰ ਕੀਤਾ ਗਿਆ ਹੈ, ਪਰ ਤੁਸੀਂ URL ਨੂੰ ਨਹੀਂ ਬਦਲ ਸਕਦੇ। ਦੂਜੇ ਦਿਨ ਹੀ ਮੈਂ ਹੈਲਪ/ਮਾਈਕ੍ਰੋਸਾਫਟ ਔਨ ਦਿ ਵੈੱਬ/ਮੁਫ਼ਤ ਸਮੱਗਰੀ ਮੀਨੂ ਵਿੱਚ Microsoft Netmeeting 2/something ਕਲਾਇੰਟ ਤੋਂ ਇੱਕ ਲਿੰਕ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ ਅਤੇ ਇੱਕ 404 ਗਲਤੀ ਪ੍ਰਾਪਤ ਕੀਤੀ - ਸਰਵਰ ਤੋਂ ਕੋਈ ਜਵਾਬ ਨਹੀਂ ਮਿਲਿਆ। ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਉਹ ਪਹਿਲਾਂ ਹੀ ਇਸ ਨੂੰ ਠੀਕ ਕਰ ਚੁੱਕੇ ਹੋਣ...

© 1998 ਟਿਮ ਬੀ.ਐਲ

ਇਤਿਹਾਸਕ ਨੋਟ: 20ਵੀਂ ਸਦੀ ਦੇ ਅਖੀਰ ਵਿੱਚ, ਜਦੋਂ ਇਹ ਲਿਖਿਆ ਗਿਆ ਸੀ, "ਕੂਲ" ਮਨਜ਼ੂਰੀ ਦਾ ਇੱਕ ਵਿਸ਼ੇਸ਼ਤਾ ਸੀ, ਖਾਸ ਕਰਕੇ ਨੌਜਵਾਨਾਂ ਵਿੱਚ, ਜੋ ਕਿ ਫੈਸ਼ਨਯੋਗਤਾ, ਗੁਣਵੱਤਾ ਜਾਂ ਅਨੁਕੂਲਤਾ ਨੂੰ ਦਰਸਾਉਂਦਾ ਸੀ। ਕਾਹਲੀ ਵਿੱਚ, URI ਮਾਰਗ ਨੂੰ ਅਕਸਰ ਉਪਯੋਗਤਾ ਜਾਂ ਟਿਕਾਊਤਾ ਦੀ ਬਜਾਏ "ਠੰਢਾ" ਲਈ ਚੁਣਿਆ ਜਾਂਦਾ ਸੀ। ਇਹ ਪੋਸਟ ਕੂਲ ਦੀ ਖੋਜ ਦੇ ਪਿੱਛੇ ਊਰਜਾ ਨੂੰ ਰੀਡਾਇਰੈਕਟ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਹੈ.

ਸਰੋਤ: www.habr.com