લેખક: સર ટિમ બર્નર્સ-લી, URIs, URLs, HTTP, HTML અને વર્લ્ડ વાઈડ વેબના શોધક અને W3C ના વર્તમાન વડા. 1998 માં લખાયેલ લેખ

કયા URIને "કૂલ" ગણવામાં આવે છે?
એક જે બદલાતું નથી.
URI કેવી રીતે બદલાય છે?
યુઆરઆઈ બદલાતા નથી: લોકો તેમને બદલે છે.

સૈદ્ધાંતિક રીતે, લોકો પાસે URI બદલવાનું કોઈ કારણ નથી (અથવા સહાયક દસ્તાવેજો બંધ કરો), પરંતુ વ્યવહારમાં તે લાખો છે.

સિદ્ધાંતમાં, ડોમેન નેમસ્પેસનો નજીવો માલિક ખરેખર ડોમેન નેમસ્પેસની માલિકી ધરાવે છે અને તેથી તેની અંદરના તમામ URIs. નાદારી સિવાય, કંઈપણ ડોમેન નામના માલિકને નામ રાખવાથી અટકાવતું નથી. અને સૈદ્ધાંતિક રીતે, તમારા ડોમેન નામ હેઠળની 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 ને સતત હોવું જોઈએ - ત્યાં URN હતા.

આ કદાચ URN ચર્ચાની સૌથી ખરાબ આડ અસરોમાંની એક છે. કેટલાક લોકો વિચારે છે કે વધુ કાયમી નેમસ્પેસમાં સંશોધનને કારણે, તેઓ લટકતી લિંક્સ વિશે બેદરકાર હોઈ શકે છે કારણ કે "URN એ બધું ઠીક કરશે." જો તમે આ લોકોમાંથી એક છો, તો ચાલો હું તમને નિરાશ કરું.

મેં જોયેલી મોટાભાગની URN સ્કીમ્સ ઓથોરિટી આઇડેન્ટિફાયર જેવી દેખાય છે, જેના પછી તમે પસંદ કરો છો તે તારીખ અને સ્ટ્રિંગ અથવા ફક્ત તમે પસંદ કરો છો તે સ્ટ્રિંગ. આ HTTP URI જેવું જ છે. બીજા શબ્દોમાં કહીએ તો, જો તમને લાગે કે તમારી સંસ્થા લાંબા ગાળાના URN બનાવવા માટે સક્ષમ હશે, તો તમારા HTTP URI માટે તેનો ઉપયોગ કરીને તેને હમણાં જ સાબિત કરો. HTTP માં જ એવું કંઈ નથી જે તમારા URIને અસ્થિર બનાવે. ફક્ત તમારી સંસ્થા. એક ડેટાબેઝ બનાવો કે જે દસ્તાવેજ URN ને વર્તમાન ફાઇલ નામ સાથે મેપ કરે છે, અને વેબ સર્વરને ખરેખર ફાઇલો પુનઃપ્રાપ્ત કરવા માટે તેનો ઉપયોગ કરવા દો.

જો તમે આ તબક્કે પહોંચી ગયા હોવ, જો તમારી પાસે અમુક સોફ્ટવેર વિકસાવવા માટે સમય, પૈસા અને જોડાણો ન હોય, તો તમે નીચેનું બહાનું કહી શકો છો:

અમે ઇચ્છતા હતા, પરંતુ અમારી પાસે યોગ્ય સાધનો નથી.

પરંતુ તમે આ સાથે સહાનુભૂતિ અનુભવી શકો છો. હું સંપૂર્ણપણે સંમત છું. તમારે જે કરવાની જરૂર છે તે વેબ સર્વરને ત્વરિત રીતે પર્સિસ્ટન્ટ યુઆરઆઈને પાર્સ કરવા અને તમારી વર્તમાન ક્રેઝી ફાઇલ સિસ્ટમ પર જ્યાં પણ તે સંગ્રહિત છે ત્યાં ફાઇલ પરત કરવા દબાણ કરવું છે. તમે ચેક તરીકે તમામ URI ને ફાઇલમાં સંગ્રહિત કરવા માંગો છો અને ડેટાબેઝને હંમેશા અદ્યતન રાખવા માંગો છો. તમે સમાન દસ્તાવેજના વિવિધ સંસ્કરણો અને અનુવાદો વચ્ચેના સંબંધને જાળવવા માંગો છો, અને ફાઇલ આકસ્મિક ભૂલથી બગડી ન જાય તેની ખાતરી કરવા માટે સ્વતંત્ર ચેકસમ રેકોર્ડ પણ જાળવી રાખવા માંગો છો. અને વેબ સર્વર્સ ફક્ત આ સુવિધાઓ સાથે બોક્સની બહાર આવતા નથી. જ્યારે તમે નવો દસ્તાવેજ બનાવવા માંગો છો, ત્યારે તમારા સંપાદક તમને URI નો ઉલ્લેખ કરવાનું કહે છે.

તમારે URI ને બદલ્યા વિના URI સ્પેસમાં માલિકી, દસ્તાવેજ ઍક્સેસ, આર્કાઇવ સ્તરની સુરક્ષા વગેરે બદલવામાં સમર્થ હોવા જરૂરી છે.

તે બધું ખૂબ ખરાબ છે. પરંતુ અમે પરિસ્થિતિ સુધારીશું. W3C પર, અમે Jigedit (જીગ્સૉ એડિટિંગ સર્વર) કાર્યક્ષમતાનો ઉપયોગ કરીએ છીએ જે સંસ્કરણોને ટ્રૅક કરે છે, અને અમે દસ્તાવેજ જનરેશન સ્ક્રિપ્ટ્સ સાથે પ્રયોગ કરીએ છીએ. જો તમે ટૂલ્સ, સર્વર્સ અને ક્લાયન્ટ્સનો વિકાસ કરો છો, તો આ મુદ્દા પર ધ્યાન આપો!

આ બહાનું ઘણા W3C પૃષ્ઠો પર પણ લાગુ પડે છે, જેમાં આનો સમાવેશ થાય છે: તેથી હું કહું તેમ કરો, હું કરું તેમ નહીં.

મારે શા માટે કાળજી લેવી જોઈએ?

જ્યારે તમે તમારા સર્વર પર URI બદલો છો, ત્યારે તમે ક્યારેય સંપૂર્ણ રીતે કહી શકતા નથી કે જૂના URIની લિંક કોની પાસે હશે. આ નિયમિત વેબ પૃષ્ઠોની લિંક્સ હોઈ શકે છે. તમારા પૃષ્ઠને બુકમાર્ક કરો. યુઆરઆઈ કદાચ મિત્રને લખેલા પત્રના હાંસિયામાં સ્ક્રોલ કરવામાં આવી હશે.

જ્યારે કોઈ લિંકને અનુસરે છે અને તે તૂટી જાય છે, ત્યારે તેઓ સામાન્ય રીતે સર્વર માલિક પરનો વિશ્વાસ ગુમાવે છે. તે પોતાના ધ્યેયને હાંસલ કરવામાં સક્ષમ ન હોવાને કારણે, ભાવનાત્મક અને શારીરિક બંને રીતે હતાશ પણ છે.

ઘણા બધા લોકો તૂટેલી લિંક્સ વિશે હંમેશા ફરિયાદ કરે છે, અને મને આશા છે કે નુકસાન સ્પષ્ટ છે. હું આશા રાખું છું કે જ્યાં દસ્તાવેજ અદૃશ્ય થઈ ગયો હતો તે સર્વરના જાળવણી કરનારને પ્રતિષ્ઠાનું નુકસાન પણ સ્પષ્ટ છે.

તો મારે શું કરવું જોઈએ? URI ડિઝાઇન

2 વર્ષમાં, 20 વર્ષમાં, 200 વર્ષમાં ઉપયોગ કરી શકાય તેવા URIs ફાળવવાની જવાબદારી વેબમાસ્ટરની છે. આ માટે વિચારશીલતા, સંગઠન અને નિશ્ચયની જરૂર છે.

જો તેમાંની કોઈપણ માહિતી બદલાય તો URI બદલાય છે. તમે તેમને કેવી રીતે ડિઝાઇન કરો છો તે ખૂબ મહત્વનું છે. (શું, URI ડિઝાઇન? શું મારે URI ડિઝાઇન કરવાની જરૂર છે? હા, તમારે તેના વિશે વિચારવું જોઈએ). મૂળભૂત રીતે ડિઝાઇનનો અર્થ એ છે કે URI માં કોઈપણ માહિતી છોડી દેવી.

દસ્તાવેજ બનાવવામાં આવ્યો હતો તે તારીખ - જે તારીખ URI જારી કરવામાં આવી હતી - તે એવી વસ્તુ છે જે ક્યારેય બદલાશે નહીં. નવી સિસ્ટમનો ઉપયોગ કરતા પ્રશ્નોને જુની સિસ્ટમનો ઉપયોગ કરતા પ્રશ્નોને અલગ કરવા માટે તે ખૂબ જ ઉપયોગી છે. URI સાથે પ્રારંભ કરવા માટે આ એક સારી જગ્યા છે. જો કોઈ દસ્તાવેજની તારીખ હોય, તો પણ ભવિષ્યમાં દસ્તાવેજ સંબંધિત હશે, તો આ એક સારી શરૂઆત છે.

એકમાત્ર અપવાદ એ પેજ છે જે ઇરાદાપૂર્વક "નવીનતમ" સંસ્કરણ છે, ઉદાહરણ તરીકે સમગ્ર સંસ્થા અથવા તેના મોટા ભાગ માટે.

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

મની મેગેઝિનમાં આ નવીનતમ મની ડેઇલી કૉલમ છે. આ યુઆરઆઈમાં તારીખની જરૂર ન હોવાનું મુખ્ય કારણ એ છે કે યુઆરઆઈને સંગ્રહિત કરવાનું કોઈ કારણ નથી કે જે લોગથી વધુ જીવંત રહેશે. જ્યારે પૈસા અદૃશ્ય થઈ જશે ત્યારે મની ડેઇલીનો ખ્યાલ અદૃશ્ય થઈ જશે. જો તમે સામગ્રી સાથે લિંક કરવા માંગો છો, તો તમારે તેને આર્કાઇવ્સમાં અલગથી લિંક કરવું જોઈએ:

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

(સારું લાગે છે. ધારે છે કે pathfinder.com ના જીવન દરમ્યાન "પૈસા" નો અર્થ એક જ રહેશે. ત્યાં ડુપ્લિકેટ "98" અને બિનજરૂરી ".html" છે, પરંતુ અન્યથા મજબૂત URI જેવો દેખાય છે.

શું બાજુ પર છોડવું

બધા! બનાવટની તારીખ સિવાય, યુઆરઆઈમાં કોઈપણ માહિતી મૂકવી એ એક યા બીજી રીતે મુશ્કેલી માટે પૂછે છે.

• લેખકનું નામ. નવા સંસ્કરણો ઉપલબ્ધ થતાં લેખકત્વ બદલાઈ શકે છે. લોકો સંસ્થાઓ છોડી દે છે અને વસ્તુઓ અન્યને આપે છે.
• વસ્તુ. તે ખૂબ જ મુશ્કેલ છે. તે હંમેશા પ્રથમ સારી દેખાય છે, પરંતુ આશ્ચર્યજનક રીતે ઝડપથી બદલાય છે. હું નીચે આ વિશે વધુ વાત કરીશ.
• સ્થિતિ. "જૂની", "ડ્રાફ્ટ" અને તેથી વધુ જેવી ડિરેક્ટરીઓ, "લેટેસ્ટ" અને "કૂલ" નો ઉલ્લેખ ન કરવા માટે, બધી ફાઇલ સિસ્ટમમાં દેખાય છે. દસ્તાવેજોની સ્થિતિ બદલાય છે - અન્યથા ડ્રાફ્ટ્સ બનાવવાનો કોઈ અર્થ રહેશે નહીં. દસ્તાવેજના નવીનતમ સંસ્કરણને તેની સ્થિતિને ધ્યાનમાં લીધા વિના, સતત ઓળખકર્તાની જરૂર છે. સ્ટેટસને નામની બહાર રાખો.
• ક્સેસ. 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), પરંતુ તમે તેના વિના વેબ સંસાધન સાથે લિંક કરી શકો છો. અપાચે પછી તે નામ અને કોઈપણ એક્સ્ટેંશન સાથેની બધી ફાઇલો માટે ડિરેક્ટરી તપાસે છે અને સેટમાંથી શ્રેષ્ઠ પસંદ કરી શકે છે (ઉદાહરણ તરીકે, 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 ને બદલી શકતા નથી. બીજા દિવસે જ મેં વેબ/ફ્રી સામગ્રી મેનૂ પર હેલ્પ/માઈક્રોસોફ્ટમાં માઇક્રોસોફ્ટ નેટમીટિંગ 2/સમથિંગ ક્લાયન્ટમાંથી એક લિંક અજમાવી અને 404 ભૂલ પ્રાપ્ત કરી - સર્વર તરફથી કોઈ પ્રતિસાદ મળ્યો નહીં. કદાચ તે પહેલેથી જ નિશ્ચિત છે ...

© 1998 ટિમ BL

ઐતિહાસિક નોંધ: 20મી સદીના ઉત્તરાર્ધમાં, જ્યારે આ લખવામાં આવ્યું હતું, ત્યારે "ઠંડુ" એ માન્યતાનો ઉપક્રમ હતો, ખાસ કરીને યુવાનોમાં, જે ફેશનની ક્ષમતા, ગુણવત્તા અથવા યોગ્યતા દર્શાવે છે. ઉતાવળમાં, યુઆરઆઈ પાથ ઘણીવાર ઉપયોગિતા અથવા ટકાઉપણુંને બદલે "ઠંડક" માટે પસંદ કરવામાં આવતો હતો. આ પોસ્ટ ઠંડીની શોધ પાછળની ઊર્જાને રીડાયરેક્ટ કરવાનો પ્રયાસ છે.

સોર્સ: www.habr.com