రచయిత: సర్ టిమ్ బెర్నర్స్-లీ, URIలు, URLలు, HTTP, HTML మరియు వరల్డ్ వైడ్ వెబ్ యొక్క సృష్టికర్త మరియు W3C యొక్క ప్రస్తుత అధిపతి. 1998లో రాసిన వ్యాసం

ఏ URIని "కూల్"గా పరిగణిస్తారు?
మారనిది ఒకటి.
URIలు ఎలా మార్చబడతాయి?
URIలు మారవు: వ్యక్తులు వాటిని మారుస్తారు.

సిద్ధాంతంలో, వ్యక్తులు URIలను మార్చడానికి (లేదా సహాయక పత్రాలను నిలిపివేయడానికి) ఎటువంటి కారణం లేదు, కానీ ఆచరణలో వాటిలో మిలియన్ల సంఖ్యలో ఉన్నాయి.

సిద్ధాంతంలో, డొమైన్ నేమ్‌స్పేస్ యొక్క నామమాత్ర యజమాని వాస్తవానికి డొమైన్ నేమ్‌స్పేస్‌ను కలిగి ఉంటారు మరియు అందుచేత దానిలోని అన్ని URIలు ఉంటాయి. దివాలా కాకుండా, డొమైన్ పేరు యజమాని పేరును ఉంచకుండా ఏదీ నిరోధించదు. మరియు సిద్ధాంతపరంగా, మీ డొమైన్ పేరుతో ఉన్న URI స్థలం పూర్తిగా మీ నియంత్రణలో ఉంటుంది, కాబట్టి మీరు దీన్ని మీకు నచ్చినంత స్థిరంగా చేయవచ్చు. ఇంటర్నెట్ నుండి డాక్యుమెంట్ అదృశ్యం కావడానికి చాలా మంచి కారణం ఏమిటంటే, డొమైన్ పేరును కలిగి ఉన్న కంపెనీ వ్యాపారం నుండి బయటపడింది లేదా సర్వర్‌ను అమలులో ఉంచుకోలేకపోతుంది. అలాంటప్పుడు ప్రపంచంలో చాలా మిస్సింగ్ లింకులు ఎందుకు ఉన్నాయి? వీటిలో కొన్ని కేవలం ముందుచూపు లేకపోవడం మాత్రమే. మీరు వినగలిగే కొన్ని కారణాలు ఇక్కడ ఉన్నాయి:

మేము ఇప్పుడే సైట్‌ను మెరుగుపరచడం కోసం పునర్వ్యవస్థీకరించాము.

పాత URIలు ఇకపై పని చేయలేవని మీరు నిజంగా అనుకుంటున్నారా? అలా అయితే, మీరు వాటిని చాలా పేలవంగా ఎంచుకున్నారు. తదుపరి పునఃరూపకల్పన కోసం కొత్త వాటిని ఉంచడాన్ని పరిగణించండి.

మా వద్ద చాలా అంశాలు ఉన్నాయి, ఏది పాతది, ఏది గోప్యమైనది మరియు ఇంకా సంబంధితంగా ఉన్న వాటిని మేము ట్రాక్ చేయలేము, కాబట్టి అన్నింటినీ ఆఫ్ చేయడం ఉత్తమమని మేము భావించాము.

నేను సానుభూతి మాత్రమే చెప్పగలను. W3C మేము వాటిని పబ్లిక్ చేయడానికి ముందు గోప్యత కోసం ఆర్కైవల్ మెటీరియల్‌లను జాగ్రత్తగా జల్లెడ పట్టాల్సిన కాలం గడిచింది. నిర్ణయం ముందుగానే ఆలోచించబడాలి - ప్రతి పత్రంతో మీరు ఆమోదయోగ్యమైన రీడర్‌షిప్, సృష్టి తేదీ మరియు, ఆదర్శంగా, గడువు తేదీని రికార్డ్ చేశారని నిర్ధారించుకోండి. ఈ మెటాడేటాను సేవ్ చేయండి.

సరే, మేము ఫైల్‌లను తరలించాలని కనుగొన్నాము...

ఇది అత్యంత దయనీయమైన సాకులలో ఒకటి. ఆబ్జెక్ట్ యొక్క URI మరియు ఫైల్ సిస్టమ్‌లో దాని వాస్తవ స్థానం మధ్య సంబంధాన్ని నియంత్రించడానికి వెబ్ సర్వర్లు మిమ్మల్ని అనుమతిస్తాయని చాలా మందికి తెలియదు. 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

ఇక్కడ పబ్‌లు/1998 హెడర్ ఏదైనా భవిష్యత్ ఆర్కైవల్ సేవకు పాత 1998 డాక్యుమెంట్ క్లాసిఫికేషన్ స్కీమ్ అమలులో ఉందని మంచి క్లూని ఇస్తుంది. 2098లో డాక్యుమెంట్ నంబర్‌లు భిన్నంగా కనిపించినప్పటికీ, ఈ URI ఇప్పటికీ చెల్లుబాటు అవుతుందని మరియు NSF లేదా ఆర్కైవ్‌ను నిర్వహించే ఏ ఇతర సంస్థతోనూ జోక్యం చేసుకోదని నేను ఊహించాను.

URLలు నిరంతరంగా ఉండాలని నేను అనుకోలేదు - URNలు ఉన్నాయి.

ఇది బహుశా URN చర్చ యొక్క చెత్త దుష్ప్రభావాలలో ఒకటి. కొంతమంది వ్యక్తులు మరింత శాశ్వత నేమ్‌స్పేస్‌పై పరిశోధన కారణంగా, డాంగ్లింగ్ లింక్‌ల గురించి అజాగ్రత్తగా ఉండవచ్చని భావిస్తారు, ఎందుకంటే "URNలు అన్నింటినీ పరిష్కరిస్తాయి." మీరు ఈ వ్యక్తులలో ఒకరైతే, నేను మిమ్మల్ని నిరాశపరుస్తాను.

నేను చూసిన చాలా URN స్కీమ్‌లు మీరు ఎంచుకున్న తేదీ మరియు స్ట్రింగ్ లేదా మీరు ఎంచుకున్న స్ట్రింగ్‌ను అనుసరించి అధికార ఐడెంటిఫైయర్ లాగా కనిపిస్తాయి. ఇది HTTP URIకి చాలా పోలి ఉంటుంది. మరో మాటలో చెప్పాలంటే, మీ సంస్థ దీర్ఘకాలిక URNలను సృష్టించగలదని మీరు భావిస్తే, వాటిని మీ HTTP URIల కోసం ఉపయోగించడం ద్వారా ఇప్పుడే నిరూపించండి. HTTPలోనే మీ URIని అస్థిరంగా చేసేది ఏదీ లేదు. మీ సంస్థ మాత్రమే. డాక్యుమెంట్ URNని ప్రస్తుత ఫైల్ పేరుకు మ్యాప్ చేసే డేటాబేస్‌ను సృష్టించండి మరియు ఫైల్‌లను తిరిగి పొందడానికి వెబ్ సర్వర్‌ని ఉపయోగించనివ్వండి.

మీరు ఈ స్థాయికి చేరుకున్నట్లయితే, కొన్ని సాఫ్ట్‌వేర్‌లను అభివృద్ధి చేయడానికి మీకు సమయం, డబ్బు మరియు కనెక్షన్‌లు లేకపోతే, మీరు ఈ క్రింది సాకును చెప్పవచ్చు:

మేము కోరుకున్నాము, కానీ మా వద్ద సరైన సాధనాలు లేవు.

కానీ మీరు దీనితో సానుభూతి పొందవచ్చు. నేను పూర్తిగా ఏకీభవిస్తున్నాను. మీరు చేయాల్సిందల్లా వెబ్ సర్వర్‌ని తక్షణమే నిరంతర URIని అన్వయించమని మరియు ఫైల్‌ను ప్రస్తుతం మీ ప్రస్తుత క్రేజీ ఫైల్ సిస్టమ్‌లో ఎక్కడ నిల్వ ఉంచబడిందో దాన్ని తిరిగి పంపమని బలవంతం చేయడం. మీరు చెక్‌గా అన్ని URIలను ఫైల్‌లో నిల్వ చేయాలనుకుంటున్నారు మరియు డేటాబేస్‌ను ఎప్పటికప్పుడు తాజాగా ఉంచాలి. మీరు ఒకే పత్రం యొక్క విభిన్న సంస్కరణలు మరియు అనువాదాల మధ్య సంబంధాన్ని సంరక్షించాలనుకుంటున్నారు మరియు ఫైల్ ప్రమాదవశాత్తూ లోపంతో పాడైపోలేదని నిర్ధారించుకోవడానికి స్వతంత్ర చెక్‌సమ్ రికార్డ్‌ను కూడా నిర్వహించాలి. మరియు వెబ్ సర్వర్‌లు ఈ లక్షణాలతో బాక్స్ నుండి బయటకు రావు. మీరు కొత్త పత్రాన్ని సృష్టించాలనుకున్నప్పుడు, మీ ఎడిటర్ మిమ్మల్ని URIని పేర్కొనమని అడుగుతారు.

మీరు URIని మార్చకుండానే URI స్పేస్‌లో యాజమాన్యం, డాక్యుమెంట్ యాక్సెస్, ఆర్కైవ్ స్థాయి భద్రత మొదలైనవాటిని మార్చగలగాలి.

ఇది చాలా చెడ్డది. కానీ మేము పరిస్థితిని సరిచేస్తాము. W3Cలో, మేము సంస్కరణలను ట్రాక్ చేసే జిగెడిట్ (జా ఎడిటింగ్ సర్వర్) కార్యాచరణను ఉపయోగిస్తాము మరియు మేము డాక్యుమెంట్ జనరేషన్ స్క్రిప్ట్‌లతో ప్రయోగాలు చేస్తాము. మీరు సాధనాలు, సర్వర్లు మరియు క్లయింట్‌లను అభివృద్ధి చేస్తే, ఈ సమస్యపై శ్రద్ధ వహించండి!

ఈ సాకు దీనితో సహా అనేక W3C పేజీలకు కూడా వర్తిస్తుంది: కాబట్టి నేను చెప్పినట్లు చేయండి, నేను చేసినట్లు కాదు.

ఎందుకు నేను జాగ్రత్త తీసుకోవాలి?

మీరు మీ సర్వర్‌లో URIని మార్చినప్పుడు, పాత URIకి ఎవరు లింక్‌లను కలిగి ఉంటారో మీరు పూర్తిగా చెప్పలేరు. ఇవి సాధారణ వెబ్ పేజీల నుండి లింక్‌లు కావచ్చు. మీ పేజీని బుక్‌మార్క్ చేయండి. URI స్నేహితుడికి వ్రాసిన లేఖ యొక్క అంచులలో స్క్రాల్ చేయబడి ఉండవచ్చు.

ఎవరైనా లింక్‌ను అనుసరించినప్పుడు మరియు అది విచ్ఛిన్నమైనప్పుడు, వారు సాధారణంగా సర్వర్ యజమానిపై నమ్మకాన్ని కోల్పోతారు. అతను తన లక్ష్యాన్ని సాధించలేక మానసికంగా మరియు శారీరకంగా కూడా నిరాశకు గురవుతాడు.

చాలా మంది వ్యక్తులు విరిగిన లింక్‌ల గురించి ఎప్పటికప్పుడు ఫిర్యాదు చేస్తారు మరియు నష్టం స్పష్టంగా ఉందని నేను ఆశిస్తున్నాను. పత్రం అదృశ్యమైన సర్వర్ యొక్క మెయింటెయినర్‌కు ప్రతిష్ట నష్టం కూడా స్పష్టంగా ఉందని నేను ఆశిస్తున్నాను.

అయితే నేను ఏమి చేయాలి? URI డిజైన్

2 సంవత్సరాలలో, 20 సంవత్సరాలలో, 200 సంవత్సరాలలో ఉపయోగించగల URIలను కేటాయించడం వెబ్‌మాస్టర్ యొక్క బాధ్యత. దీనికి ఆలోచనాత్మకత, సంస్థ మరియు సంకల్పం అవసరం.

వాటిలో ఏదైనా సమాచారం మారితే 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లో ఏదైనా సమాచారాన్ని ఉంచడం అనేది ఒక మార్గం లేదా మరొక విధంగా ఇబ్బందిని అడుగుతోంది.

• రచయిత పేరు. కొత్త సంస్కరణలు అందుబాటులోకి వచ్చినప్పుడు రచయిత హక్కు మారవచ్చు. వ్యక్తులు సంస్థలను విడిచిపెట్టి, ఇతరులకు విషయాలను అందజేస్తారు.
• Subject. ఇది చాలా కష్టం. ఇది ఎల్లప్పుడూ మొదట్లో బాగుంది, కానీ ఆశ్చర్యకరంగా త్వరగా మారుతుంది. నేను దీని గురించి మరింత క్రింద మాట్లాడుతాను.
• స్థితి. "పాత", "డ్రాఫ్ట్" మొదలైన డైరెక్టరీలు, "తాజా" మరియు "కూల్" అని చెప్పకుండా, అన్ని ఫైల్ సిస్టమ్‌లలో కనిపిస్తాయి. పత్రాలు స్థితిని మారుస్తాయి - లేకపోతే చిత్తుప్రతులను రూపొందించడంలో అర్థం ఉండదు. పత్రం యొక్క తాజా సంస్కరణకు దాని స్థితితో సంబంధం లేకుండా నిరంతర ఐడెంటిఫైయర్ అవసరం. హోదాను పేరుకు దూరంగా ఉంచండి.
• యాక్సెస్. W3Cలో, మేము సైట్‌ను ఉద్యోగులు, సభ్యులు మరియు పబ్లిక్ కోసం విభాగాలుగా విభజించాము. ఇది బాగానే ఉంది, అయితే, పత్రాలు సిబ్బంది నుండి టీమ్ ఐడియాలుగా ప్రారంభమవుతాయి, సభ్యులతో చర్చించబడతాయి, ఆపై పబ్లిక్ నాలెడ్జ్ అవుతాయి. ఒక డాక్యుమెంట్‌ని విస్తృత చర్చకు తెరిచిన ప్రతిసారీ, దానికి సంబంధించిన పాత లింకులన్నీ తెగిపోతే అది నిజంగా అవమానకరం! ఇప్పుడు మనం సాధారణ తేదీ కోడ్‌కి వెళ్తాము.
• ఫైల్ పొడిగింపు. చాలా సాధారణ సంఘటన. భవిష్యత్తులో "cgi", ".html" కూడా మారుతుంది. మీరు 20 సంవత్సరాలలో ఈ పేజీ కోసం HTMLని ఉపయోగించకపోవచ్చు, కానీ దానికి నేటి లింక్‌లు ఇప్పటికీ పని చేస్తాయి. W3C సైట్‌లోని కానానికల్ లింక్‌లు పొడిగింపును ఉపయోగించవు (అది ఎలా జరిగింది).
• సాఫ్ట్‌వేర్ మెకానిజమ్స్. URIలో, "cgi", "exec" మరియు "మేము ఏ సాఫ్ట్‌వేర్ ఉపయోగిస్తున్నామో చూడండి" అని అరిచే ఇతర పదాల కోసం చూడండి. ఎవరైనా పెర్ల్ CGI స్క్రిప్ట్‌లు రాయడానికి తమ జీవితాంతం గడపాలనుకుంటున్నారా? కాదా? తర్వాత .pl పొడిగింపును తీసివేయండి. దీన్ని ఎలా చేయాలో సర్వర్ మాన్యువల్ చదవండి.
• డిస్క్ పేరు. రా! కానీ నేను దీనిని చూశాను.

కాబట్టి మా సైట్ నుండి ఉత్తమ ఉదాహరణ కేవలం

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

... W3C కుర్చీల సమావేశం యొక్క నిమిషాల నివేదిక.

అంశం వారీగా అంశాలు మరియు వర్గీకరణ

నేను ఈ ప్రమాదం గురించి మరింత వివరంగా తెలియజేస్తాను, ఎందుకంటే ఇది నివారించడం చాలా కష్టమైన వాటిలో ఒకటి. సాధారణంగా, మీరు మీ పత్రాలను వారు చేసే పనిని బట్టి వర్గీకరించినప్పుడు అంశాలు URIలలో ముగుస్తాయి. కానీ ఈ విచ్ఛిన్నం కాలక్రమేణా మారుతుంది. ప్రాంతాల పేర్లు మారుతాయి. W3C వద్ద మేము విభాగం యొక్క వాస్తవ కంటెంట్‌ను ప్రతిబింబించేలా MarkUPని మార్కప్‌కి ఆపై HTMLకి మార్చాలనుకుంటున్నాము. అదనంగా, తరచుగా ఫ్లాట్ నేమ్‌స్పేస్ ఉంటుంది. 100 సంవత్సరాలలో, మీరు దేనినీ తిరిగి ఉపయోగించకూడదనుకుంటున్నారా? మా చిన్న జీవితంలో మేము ఇప్పటికే ఉదాహరణకు "చరిత్ర" మరియు "స్టైల్ షీట్‌లను" తిరిగి ఉపయోగించాలనుకుంటున్నాము.

ఇది వెబ్‌సైట్‌ను నిర్వహించడానికి ఉత్సాహం కలిగించే మార్గం-మరియు మొత్తం వెబ్‌తో సహా ఏదైనా నిర్వహించడానికి ఇది నిజంగా ఉత్సాహం కలిగించే మార్గం. ఇది ఒక గొప్ప మధ్యకాలిక పరిష్కారం అయితే దీర్ఘకాలంలో తీవ్రమైన లోపాలను కలిగి ఉంటుంది.

కారణం యొక్క భాగం అర్థం యొక్క తత్వశాస్త్రంలో ఉంది. ఒక భాషలోని ప్రతి పదం క్లస్టరింగ్‌కు సంభావ్య లక్ష్యం, మరియు ప్రతి వ్యక్తికి దాని అర్థం గురించి వేరే ఆలోచన ఉండవచ్చు. ఎంటిటీల మధ్య సంబంధాలు చెట్టు కంటే వెబ్ లాగా ఉంటాయి కాబట్టి, వెబ్‌తో ఏకీభవించే వారు కూడా చెట్టుకు భిన్నమైన ప్రాతినిధ్యాన్ని ఎంచుకోవచ్చు. ఇవి సాధారణ పరిష్కారంగా క్రమానుగత వర్గీకరణ యొక్క ప్రమాదాల గురించి నా (తరచుగా పునరావృతమయ్యే) సాధారణ పరిశీలనలు.

వాస్తవానికి, మీరు URIలో టాపిక్ పేరును ఉపయోగించినప్పుడు, మీరు ఒక రకమైన వర్గీకరణకు కట్టుబడి ఉంటారు. బహుశా భవిష్యత్తులో మీరు వేరే ఎంపికను ఇష్టపడతారు. URI అప్పుడు ఉల్లంఘనకు అవకాశం ఉంటుంది.

URIలో భాగంగా సబ్జెక్ట్ ఏరియాని ఉపయోగించడానికి కారణం ఏమిటంటే, URI స్పేస్‌లోని సబ్‌సెక్షన్‌లకు బాధ్యత సాధారణంగా అప్పగించబడుతుంది, ఆపై మీకు ఆ సబ్‌స్పేస్‌కు బాధ్యత వహించే సంస్థాగత సంస్థ పేరు - విభాగం, సమూహం లేదా ఏదైనా అవసరం. ఇది సంస్థాగత నిర్మాణానికి URI బైండింగ్. తదుపరి (ఎడమవైపు) URI తేదీ ద్వారా రక్షించబడినట్లయితే మాత్రమే ఇది సాధారణంగా సురక్షితం: 1998/పిక్స్ మీ సర్వర్‌కు "1998లో మేము చిత్రాలతో ఏమి అర్థం చేసుకున్నాము" అని కాకుండా "1998లో మనం ఇప్పుడు జగన్ అని పిలుస్తున్న దానితో ఏమి చేసాము" అని అర్థం కావచ్చు.

డొమైన్ పేరును మర్చిపోవద్దు

ఇది URIలోని మార్గానికి మాత్రమే కాకుండా, సర్వర్ పేరుకు కూడా వర్తిస్తుందని గుర్తుంచుకోండి. మీరు వేర్వేరు విషయాల కోసం ప్రత్యేక సర్వర్‌లను కలిగి ఉంటే, అనేక, అనేక లింక్‌లను నాశనం చేయకుండా ఈ విభజనను మార్చడం అసాధ్యం అని గుర్తుంచుకోండి. కొన్ని క్లాసిక్ "మేము ఈ రోజు ఉపయోగించే సాఫ్ట్‌వేర్‌ను చూడండి" తప్పులు డొమైన్ పేర్లు "cgi.pathfinder.com", "secure", "lists.w3.org". సర్వర్ పరిపాలనను సులభతరం చేయడానికి అవి రూపొందించబడ్డాయి. డొమైన్ మీ కంపెనీలో ఒక డివిజన్, డాక్యుమెంట్ స్థితి, యాక్సెస్ స్థాయి లేదా భద్రతా స్థాయిని సూచిస్తుందా అనే దానితో సంబంధం లేకుండా, బహుళ డాక్యుమెంట్ రకాల కోసం ఒకటి కంటే ఎక్కువ డొమైన్ పేర్లను ఉపయోగించే ముందు చాలా జాగ్రత్తగా ఉండండి. మీరు దారి మళ్లింపు మరియు ప్రాక్సింగ్‌ని ఉపయోగించి ఒకే కనిపించే వెబ్ సర్వర్‌లో బహుళ వెబ్ సర్వర్‌లను దాచవచ్చని గుర్తుంచుకోండి.

ఓహ్, మరియు మీ డొమైన్ పేరు గురించి కూడా ఆలోచించండి. మీరు ఉత్పత్తి లైన్లను మార్చిన తర్వాత మరియు సబ్బు తయారీని ఆపివేసిన తర్వాత మీరు soap.comగా సూచించబడకూడదు (ప్రస్తుతం soap.comని కలిగి ఉన్న వారిని క్షమించండి).

తీర్మానం

URIని 2, 20, 200 లేదా 2000 సంవత్సరాల పాటు భద్రపరచడం అనేది స్పష్టంగా కనిపించినంత సులభం కాదు. అయినప్పటికీ, ఇంటర్నెట్ అంతటా, వెబ్‌మాస్టర్‌లు భవిష్యత్తులో ఈ పనిని నిజంగా కష్టతరం చేసే నిర్ణయాలు తీసుకుంటున్నారు. తరచుగా దీనికి కారణం వారు ప్రస్తుతం ఉత్తమమైన సైట్‌ను ప్రదర్శించడమే పనిగా ఉన్న సాధనాలను ఉపయోగిస్తున్నారు - మరియు ప్రతిదీ మారినప్పుడు లింక్‌లకు ఏమి జరుగుతుందో ఎవరూ అంచనా వేయలేదు. అయితే, ఇక్కడ విషయం ఏమిటంటే, చాలా, చాలా విషయాలు మారవచ్చు మరియు మీ URIలు అలాగే ఉంటాయి మరియు అలాగే ఉండాలి. మీరు వాటిని ఎలా సృష్టించాలో ఆలోచించినప్పుడు మాత్రమే ఇది సాధ్యమవుతుంది.

ఇవి కూడా చూడండి:

• ఇదే అంశంపై జాకబ్ నీల్సన్ తీవ్ర వ్యాఖ్యలు చేశారు

సప్లిమెంట్స్

ఫైల్ ఎక్స్‌టెన్షన్‌లను ఎలా తొలగించాలి...

...ప్రస్తుత ఫైల్-ఆధారిత వెబ్ సర్వర్‌లోని URI నుండి?

మీరు అపాచీని ఉపయోగిస్తే, ఉదాహరణకు, మీరు కంటెంట్‌ను చర్చించడానికి దాన్ని కాన్ఫిగర్ చేయవచ్చు. ఫైల్ పొడిగింపును (ఉదా. .png) ఫైల్‌లో సేవ్ చేయండి (ఉదా. mydog.png), కానీ మీరు అది లేకుండా వెబ్ వనరుకి లింక్ చేయవచ్చు. Apache ఆ పేరు మరియు ఏదైనా పొడిగింపుతో ఉన్న అన్ని ఫైల్‌ల కోసం డైరెక్టరీని తనిఖీ చేస్తుంది మరియు సెట్ నుండి ఉత్తమమైనదాన్ని ఎంచుకోవచ్చు (ఉదాహరణకు, GIF మరియు PNG). మరియు వేర్వేరు డైరెక్టరీలలో వివిధ రకాల ఫైల్‌లను ఉంచాల్సిన అవసరం లేదు, వాస్తవానికి మీరు అలా చేస్తే కంటెంట్ సరిపోలిక పనిచేయదు.

• కంటెంట్‌ను చర్చించడానికి మీ సర్వర్‌ని సెటప్ చేయండి
• పొడిగింపు లేకుండా ఎల్లప్పుడూ URIలకు లింక్ చేయండి

పొడిగింపులతో లింక్‌లు ఇప్పటికీ పని చేస్తాయి, కానీ ప్రస్తుతం మరియు భవిష్యత్తులో అందుబాటులో ఉన్న ఉత్తమ ఆకృతిని ఎంచుకోవడం నుండి మీ సర్వర్‌ని నిరోధిస్తుంది.

(నిజానికి, 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/సమ్‌థింగ్ క్లయింట్ నుండి లింక్‌ను ప్రయత్నించాను మరియు 404 ఎర్రర్‌ను అందుకున్నాను - సర్వర్ నుండి ఎటువంటి ప్రతిస్పందన కనుగొనబడలేదు. బహుశా ఇది ఇప్పటికే పరిష్కరించబడింది ...

© 1998 టిమ్ BL

చారిత్రక గమనిక: 20వ శతాబ్దం చివరలో, ఇది వ్రాయబడినప్పుడు, "కూల్" అనేది ఆమోదం యొక్క సారాంశం, ముఖ్యంగా యువతలో, ఫ్యాషన్, నాణ్యత లేదా సముచితతను సూచిస్తుంది. ఆతురుతలో, URI మార్గం తరచుగా ఉపయోగం లేదా మన్నిక కోసం కాకుండా "చల్లదనం" కోసం ఎంపిక చేయబడింది. ఈ పోస్ట్ చల్లని కోసం శోధన వెనుక ఉన్న శక్తిని దారి మళ్లించే ప్రయత్నం.

మూలం: www.habr.com