मैं वर्तमान में कोणीय का उपयोग कर एक वेब अनुप्रयोग लिख रहा हूं, लेकिन मुझे लगता है कि यह प्रश्न क्लाइंट साइड (as angular does) पर रूटिंग करने वाले क्लाइंट-साइड जावास्क्रिप्ट फ्रेमवर्क पर लागू होता है।एक-पेज ऐप में, गलत URL (404 त्रुटियों) से निपटने का सही तरीका क्या है?
एकल पृष्ठ ऐप में, गलत URL से निपटने का सही तरीका क्या है?
कुछ प्रमुख साइटों को देखते हुए, मुझे लगता है कि यदि आप https://mail.google.com/mail/ से नीचे कोई यादृच्छिक URL टाइप करते हैं तो जीमेल इनबॉक्स पर रीडायरेक्ट करेगा। यह सर्वर-साइड (http 300 कोड के साथ) या क्लाइंट-साइड होता है, इस पर निर्भर करता है कि गलत पथ # वर्ण से पहले या उसके बाद है या नहीं। दूसरी तरफ, ट्विटर किसी भी अवैध यूआरएल के लिए वास्तविक HTTP 404 दिखाता है। एक तीसरा विकल्प एक "मुलायम" 404, एक पूरी तरह से क्लाइंट-साइड त्रुटि पृष्ठ दिखाने के लिए होगा।
ये समाधान विभिन्न स्थितियों के लिए उपयुक्त प्रतीत होते हैं। ट्विटर ट्विटर उपयोगकर्ताओं और ट्वीट्स के लिंक वास्तविक लिंक होने के लिए चाहता है, इसलिए लोग उन्हें साझा कर सकते हैं, उन्हें समाचार लेखों आदि में पोस्ट कर सकते हैं, इसलिए यह महत्वपूर्ण है कि अमान्य लिंक इस तरह से पहचाने जाएं (यदि मेरे पास एक ट्वीट के टूटे हुए लिंक हैं मेरी वेबसाइट, एक साधारण क्रॉल मुझे बताएगा)। दूसरी तरफ, जीमेल में, आपको अपने इनबॉक्स में लिंक साझा करने की उम्मीद नहीं है, और मुझे यह भी यकीन नहीं है कि लिंक वास्तव में स्थायी/लगातार हैं: ऐसा लगता है कि यूआरएल अपडेटिंग ज्यादातर ब्राउज़र इतिहास नेविगेशन के उद्देश्य से कार्य करता है एकल पृष्ठ ऐप। नरम त्रुटियों को देने का तीसरा दृष्टिकोण जीमेल के समान स्थितियों के लिए उपयुक्त हो सकता है, लेकिन जहां कोई उचित "डिफ़ॉल्ट" पृष्ठ नहीं है।
इस लंबी शुरूआत के बाद, यहाँ कुछ विशिष्ट प्रश्न हैं:
- यह कभी स्वीकार्य एक 404 त्रुटि के बजाय एक "सॉफ्ट" त्रुटि पृष्ठ देने के लिए है, या एक एकल पृष्ठ एप्लिकेशन को हमेशा की ओर ही रीडायरेक्ट असली 404 अगर यूआरएल अमान्य है?
- जीमेल का कोड पूरी तरह से बगफ्री हो सकता है, लेकिन अगर इसमें एक बग है जो अमान्य लिंक की ओर जाता है जो इनबॉक्स पर वापस रीडायरेक्ट करना समाप्त करता है, तो यह किसी त्रुटि पृष्ठ से उपयोगकर्ताओं के लिए और भी भ्रमित हो सकता है। वहां अधिकांश वेब ऐप्स के लिए, जिन्हें जीमेल के रूप में भी परीक्षण नहीं किया गया है, क्या एक त्रुटि पृष्ठ दिखाना बेहतर होगा?
- सिंगल-पेज ऐप्स के लिए वास्तविक 404 को लागू करने के लिए, सर्वर-साइड पर रूटिंग तर्क को डुप्लिकेट करना आवश्यक लगता है। क्या इसके आसपास कोई रास्ता है?
- 404 पर रीडायरेक्ट करते समय, मुझे लगता है कि उपयोगकर्ता उस यूआरएल को देखने में सक्षम होना चाहिए जिसने त्रुटि को संभवतः यूआरएल बार में देखा है। एचटीएमएल 5 इतिहास एपीआई के साथ, मुझे लगता है कि यह उपरोक्त वर्णित सर्वर-साइड रूटिंग के साथ संयुक्त वर्तमान पृष्ठ (गलत यूआरएल के साथ) को फिर से लोड करके पूरा किया जा सकता है। ऐसे ब्राउज़र के लिए जो इसका समर्थन नहीं करते हैं या हैशबैंग नोटेशन का उपयोग करते समय, यह संभव नहीं लगता है। सभी ब्राउज़रों का समर्थन करने का सबसे अच्छा तरीका क्या है?
क्या आपकी वेबसाइट जावास्क्रिप्ट के बिना भी काम करती है? क्या आप जावास्क्रिप्ट, या यूआरएल में सेगमेंट के माध्यम से यूआरएल अपडेट करने के लिए history.pushState का उपयोग कर रहे हैं? –
इसके अलावा, आप * 404 पर रीडायरेक्ट * के बारे में क्यों बात कर रहे हैं, क्यों न केवल * दिखाएं * एक? –
@markus जिस साइट पर मैं वर्तमान में काम कर रहा हूं वह जावास्क्रिप्ट के बिना काम नहीं करता है। लेकिन मैं काम करने के लिए गहरे लिंक करना चाहता हूं, इसलिए उपयोगकर्ता साइट के अंदर लिंक साझा कर सकते हैं (आमतौर पर, यह ईमेल द्वारा होगा)। मैं अब के लिए हैशबैंग नोटेशन का उपयोग कर रहा हूं, लेकिन अगर एंजुलरज एचटीएमएल 5 पुशस्टेट पर स्विच करना आसान बनाता है तो मुझे चाहिए/जरूरत है। – jssebastian