wwws.site.com क्या है


10

मुझे पता है कि लॉगिन और इस तरह के महत्वपूर्ण पेज हासिल करने के लिए https के बारे में। लेकिन कोई www। जैसे अलग उपडोमेन भी क्यों बनाएगा? उदाहरण के लिए

https://wwws.site.com/login


2
इसका php से क्या संबंध है?

जब सामान्य गैर तकनीकी / इंटरनेट लोग "www" को URL में देखते हैं तो यह या तो उन्हें बेहतर महसूस कराता है या उन्हें लगता है कि यह वहां होना है। क्या आपने कभी किसी ग्राहक को sub.domain.com पर जाने की कोशिश की है और www.sub.domain.com पर जाने के कारण वे वहां नहीं पहुंचे? किसी को बताने पर wwws.domain.com पर जाते हैं और वे अब अतिरिक्त www छोड़ देंगे। वह मेरे अनुभव से सिर्फ मेरा सिद्धांत है।
केल

जवाबों:


8

ऐसा करने का कोई अच्छा कारण नहीं है। कुछ विपणन व्यक्ति ने शायद इसका सुझाव दिया था।

वास्तव में, यह एक बुरा विचार है, क्योंकि यह उपयोगकर्ताओं को होस्ट नाम पर भरोसा करना सिखाता है न कि ब्राउज़र के सुरक्षा संकेतक (लॉक आइकन, आदि)।


1
@Paul Schreiber क्या आप बता सकते हैं कि यह विपणन के लिए भी कैसे लाभकारी हो सकता है। मुझे यह बिल्कुल नहीं सूझ रहा है कि उन्होंने ऐसा क्यों किया।
silow

2
वे शायद एक विचार को बेचने की कोशिश कर रहे हैं। यही विपणक करते हैं। बिंदु @Paul बना रहा है कि www बिल्कुल कुछ नहीं करता है। यह सिर्फ एक नाम है, जैसे blog.example.com या home.example.com या www.example.com। wwws सिर्फ एक और नाम है, लेकिन यह एक शौकिया सोच सकता है कि साइट सुरक्षित है भले ही वह न हो। http या https वह है जो आपको बताता है कि क्या कनेक्शन सुरक्षित है।
jmort253

@ jmort253- अधिक सटीक रूप से, सभी http / https आपको बताता है कि क्या वेब सर्वर http या https चला रहा है, जो आपको बेहतर संकेत दे सकता है कि क्या कनेक्शन सुरक्षित है।
रोर अलसॉप

2
यदि आपके पास HTTPS ट्रैफ़िक के लिए एक अलग सर्वर (या वर्चुअल साइट) है, तो इसे अपने स्वयं के उप-डोमेन पर असाइन करना असामान्य नहीं है। "wwws" सिर्फ एक छोटी - अगर अस्पष्ट - इस प्रथा का संस्करण हो सकता है।
याकूब ह्यूम

5

मैं ऐसा करता हूं (हालांकि मैं आमतौर पर Secure.site.com या इसी तरह का उपयोग करता हूं) जब मेरे पास सेवा करने के लिए अलग सामग्री होती है। यानी, जब site.com और safe.site.com में अलग-अलग चीजें हैं और / या उन पर अलग-अलग प्रतिबंध हैं (यानी, स्रोत आईपी पता) उनका उपयोग कर सकते हैं। यदि वे दोनों समान सामग्री परोस रहे हैं, तो मुझे यकीन नहीं है कि आप ऐसा क्यों करेंगे - मुझे इसका कोई लाभ नहीं दिखता है। मुझे लगता है कि यह सिर्फ इस तरह से किया गया था क्योंकि इसे सेट करने वाले व्यक्ति को नहीं पता था कि HTTP और HTTPS दोनों को एक ही डोमेन में एक ही डोमेन पर कैसे कॉन्फ़िगर किया जाए।


1
रिकॉर्ड के लिए, मुझे लगता है कि यह एक बहुत बुरा विचार है। मान लीजिए कि आपका कॉन्फ़िगरेशन गड़बड़ हो गया है और कोई व्यक्ति http://secure.site.com पर चला गया है और आपका रीडायरेक्ट https में विफल हो गया है?
jmort253

2
कोई गैर-एसएसएल Secure.site.com नहीं है - आप गलत तरीके से मान रहे हैं कि कोई रीडायरेक्ट है। भले ही, आपका बयान एक हास्यास्पद तर्क है, क्योंकि आप अनुमान लगा रहे हैं कि कुछ अन्य परिदृश्य हैं जो इसके कॉन्फ़िगरेशन के खराब होने पर अलग नहीं हो सकते।
एलेक्स हॉवान्स्की

3

एचपी ऐसा करता था, और वे अब भी कर सकते हैं। इस प्रकार वे अपनी साइट को संतुलित करते हैं। प्रत्येक उप डोमेन एक अलग आईपी पते के साथ जुड़ा हो सकता है और www.hp.com पर लॉग इन करने पर आपको www1.hp.com में से एक पर पुनर्निर्देशित किया जाएगा ... आदि मुझे लगता है कि सीडीएन के आने से पहले एक समय हो सकता है। उनके अपने, अमेजन ने भी यही काम किया।

कभी-कभी यह खराब एप्लिकेशन डिज़ाइन के कारण होता है, जिसमें वेबसाइट वर्जन 1 को होस्ट करने वाला सर्वर 68.68.68.2 (www.domain.com) पर होस्ट किया जाता है और फिर कोई व्यक्ति वेबसाइट को फिर से लिखता है क्योंकि टेक्सास का आपका डेवलपर अब जेल में है (सच्ची कहानी ... ) और www.domain.com पर बकवास के ढेर में दबे हुए कुछ XML-RPC तर्क की अभी भी जरूरत है, हम सिर्फ अपने उपयोगकर्ताओं को wwws.domain.com (68.68.68.3) पर पुनर्निर्देशित करते हैं, जहां हमारी नई और बेहतर साइट है जिसे विकसित किया गया था ब्रायन असंतुष्ट पूर्व Microsoft कर्मचारी।

हमें यकीन नहीं है कि अगर हम www.domain.com को छोड़ देते हैं या इसे स्थानांतरित कर देते हैं या इसका नाम बदल देते हैं, तो क्या होगा, इसलिए हम अपनी प्राथमिक वेबसाइट पर वापस अपनी 'अच्छी' वेबसाइट को स्थानांतरित करने के बजाय इसे छोड़ देते हैं।


1
इस घटना के पीछे का तर्क है या नहीं, मैं यह सोचना चाहूंगा कि एक आपराधिक विश्वास अक्सर नामकरण योजनाओं के पीछे प्रेरणा है। : डी
जैकब ह्यूम
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.