2011-08-16 6 views
6

ऐसे उपयोगकर्ता हैं जहां उपयोगकर्ता एक यूआरएल दर्ज कर सकते हैं जहां वे एक यूआरएल दर्ज करेंगे (उनकी व्यक्तिगत वेबसाइट, व्यवसाय साइट, पसंदीदा साइट इत्यादि)।क्या "http: //" को यूआरएल के डेटाबेस रिकॉर्ड के साथ संग्रहीत किया जाना चाहिए?

यह एकमात्र चीज है जो वे उस विशेष क्षेत्र में प्रवेश कर रहे हैं।

तो क्या मुझे इसे हमेशा बनाए रखने के लिए "http: //" को अलग करना चाहिए और टूटी हुई लिंक (यानी "http //") की संभावना को कम करना चाहिए?

बस यह सुनिश्चित न करें कि यूआरएल स्टोर करने का सबसे अच्छा तरीका क्या है।

+3

क्या इसे हटाने का कोई कारण है? उस और HTTPS के बीच अंतर करने के बारे में क्या? मैं कहूंगा कि एक प्रोटोकॉल वाला यूआरएल बिना किसी के मुकाबले ज्यादा उपयोगी है। स्थिरता के लिए –

+0

। तो जो श्मो "http: //" दर्ज कर सकता है जबकि बॉब स्मिथ इसे दर्ज नहीं कर सकता है। जब मैं लिंक आउटपुट करता हूं तो मुझे इसे सुसंगत होने की आवश्यकता होती है। Https के मामलों में – Shpigford

+0

, यदि कोई उपयोग http प्रकार करता है तो सर्वर स्वचालित रूप से https पर रीडायरेक्ट करता है। इसलिए यदि http जोड़ा गया है तो कोई नुकसान नहीं हुआ है – nonouco

उत्तर

6

यदि आपके उपयोगकर्ताओं के इनपुट (सुरक्षा, आकार, गति, सटीकता ...) को स्वच्छ करने का कोई कारण है तो इसे करें।

लेकिन अन्यथा, नहीं।

वास्तव में आपके ग्राहक-इनपुट डेटा को लेने में कई बार लाभ होता है। वे अपने स्वयं के टाइपो या गलत वर्तनी, टूटे हुए लिंक इत्यादि के मालिक हैं। जब तक यह आपके लिए कोई समस्या नहीं पैदा करता है (यानी आपके पास इसे स्वच्छ करने का कोई कारण नहीं है)।

बीटीडब्लू - स्थिरता एक महत्वपूर्ण बिंदु है, क्योंकि यह डेटा प्रकार नहीं बदलेगा, और आप आसानी से "http: //" की जांच कर सकते हैं और इसे अपनी प्रस्तुति परतों में आवश्यकतानुसार जोड़ या हटा सकते हैं अनुकूल कार्य

5

जहाँ तक मुझे पता है कि आप वास्तव में के रूप में एक "URL", यह फोन नहीं कर सकते हैं प्रोटोकॉल हिस्सा बिना:

http://www.w3.org/Addressing/URL/url-spec.txt

मैं इसे नहीं निकलेगी।

हालांकि यदि आपको वास्तव में डेटा को लगातार रखने की आवश्यकता है, तो यह वास्तव में निर्भर करता है कि यूआरएल वास्तव में आपके आवेदन में कैसे टाइप किया जाता है। यदि यह एक ब्राउज़र जैसा अनुप्रयोग है, तो मैं शर्त लगाता हूं कि वैध लिंक के लिए इसे कोई भी नहीं होने पर http: // के सामने माना जा सकता है।

 संबंधित मुद्दे

  • कोई संबंधित समस्या नहीं^_^