2011-11-30 16 views
17

के लिए HTTP स्थिति कोड मुझे आश्चर्य है कि मुझे कौन सी HTTP स्थिति कोड भाषा रीडायरेक्ट में भेजना होगा।भाषा रीडायरेक्ट

मेरे पास HTTP शीर्षलेखों के माध्यम से स्वीकार्य-भाषा ब्राउज़र शीर्षलेख में सबसे महत्वपूर्ण भाषा में रीडायरेक्ट करने के लिए निम्न PHP कोड है।

<? 
$langs = array(); 

if (isset($_SERVER['HTTP_ACCEPT_LANGUAGE'])) { 
    // break up string into pieces (languages and q factors) 
    preg_match_all('/([a-z]{1,8}(-[a-z]{1,8})?)\s*(;\s*q\s*=\s*(1|0\.[0-9]+))?/i', $_SERVER['HTTP_ACCEPT_LANGUAGE'], $lang_parse); 

    if (count($lang_parse[1])) { 
     // create a list like "en" => 0.8 
     $langs = array_combine($lang_parse[1], $lang_parse[4]); 

     // set default to 1 for any without q factor 
     foreach ($langs as $lang => $val) { 
      if ($val === '') $langs[$lang] = 1; 
     } 

     // sort list based on value 
     arsort($langs, SORT_NUMERIC); 
    } 
} 

// look through sorted list and use first one that matches our languages 
foreach ($langs as $lang => $val) { 
    if (strpos($lang, 'ca')===0) { 
    header("location: ca/"); 
    exit; 
    } else if (strpos($lang, 'es')===0) { 
    header("location: es/"); 
    exit; 
    } 
    echo "$lang => $val<br>"; 
} 
// show default site or prompt for language 
header("location: en/"); 

?> 

संबंधित प्रश्न: HTTP status for functional redirect

हो सकता है कि 300, 301, 302, 303? क्यूं कर?

HTTP स्थिति 300 अनेक विकल्प

अनुरोध किए गए संसाधन में से किसी एक से मेल खाती है: http://googlewebmastercentral.blogspot.com/2011/12/new-markup-for-multilingual-content.html

मैं इस पाया:

संपादित

गूगल ने हाल ही यह प्रकाशित प्रस्तुतियों का सेट, प्रत्येक अपने स्वयं के spec के साथ ific location, और agent- संचालित वार्तालाप जानकारी (सेक्शन 12) प्रदान की जा रही है ताकि उपयोगकर्ता (या उपयोगकर्ता एजेंट) एक पसंदीदा प्रतिनिधित्व का चयन कर सके और उस स्थान पर इसके अनुरोध को पुनर्निर्देशित कर सके।

जब तक यह एक HEAD अनुरोध नहीं था, प्रतिक्रिया में शामिल होना चाहिए जिसमें से संसाधन विशेषताओं और स्थान की एक सूची शामिल है जिसमें उपयोगकर्ता या उपयोगकर्ता एजेंट सबसे उपयुक्त विकल्प चुन सकता है। इकाई प्रारूप सामग्री- में दिए गए मीडिया प्रकार द्वारा निर्दिष्ट हैडर हेडर फ़ील्ड टाइप करें।

उपयोगकर्ता एजेंट, सबसे उचित विकल्प का चयन के प्रारूप और क्षमताओं के आधार पर स्वचालित रूप से किया जा सकता है। हालांकि, यह विनिर्देश को ऐसे स्वचालित चयन के लिए किसी भी मानक को परिभाषित नहीं करता है।

यदि सर्वर का प्रतिनिधित्व करने का पसंदीदा विकल्प है, तो में फ़ील्ड में उस प्रतिनिधित्व के लिए विशिष्ट यूआरआई शामिल होना चाहिए; उपयोगकर्ता एजेंट स्वचालित पुनर्निर्देशन के लिए स्थान फ़ील्ड मान का उपयोग कर सकते हैं। यह प्रतिक्रिया तब तक कैशबल है जब तक कि अन्यथा इंगित न किया जाए।

और यह:

HTTP त्रुटि 300 - एकाधिक विकल्प

परिचय

अपने वेब सर्वर का मानना ​​है कि ग्राहक द्वारा प्रदत्त URL (जैसे अपने वेब ब्राउज़र या हमारे CheckUpDown रोबोट) पर्याप्त विशिष्ट नहीं है, और आगे के चयन को कई विकल्पों से बनाया जाना चाहिए।

यह आमतौर पर ऐसा मामला है जहां यूआरएल उच्च स्तर समूह का प्रतिनिधित्व करता है जिसमें निम्न स्तर के चयन किए जाने की आवश्यकता है। निर्देशिका जिसके भीतर उपयोगकर्ता को पहुंच पर एक विशेष फ़ाइल का चयन करना होगा।HTTP चक्र में

300 त्रुटियों

कोई भी क्लाइंट (जैसे अपने वेब ब्राउज़र या हमारे CheckUpDown रोबोट) निम्नलिखित चक्र के माध्यम से चला जाता है जब यह वेब सर्वर के साथ संचार:

से IP पता प्राप्त करें साइट के आईपी नाम (साइट यूआरएल अग्रणी 'http: //' के बिना)। यह लुकअप (आईपी नाम का रूपांतरण आईपी पता) डोमेन नाम सर्वर (डीएनएस) द्वारा प्रदान किया जाता है। उस आईपी पते पर आईपी सॉकेट कनेक्शन खोलें। उस सॉकेट के माध्यम से HTTP डेटा स्ट्रीम लिखें। प्रतिक्रिया में वेब सर्वर से एक HTTP डेटा स्ट्रीम वापस प्राप्त करें। इस डेटा स्ट्रीम में स्टेटस कोड होते हैं जिनके मान HTTP प्रोटोकॉल द्वारा निर्धारित किए जाते हैं। स्थिति कोड और अन्य उपयोगी जानकारी के लिए इस डेटा स्ट्रीम को पार्स करें। यह त्रुटि उपरोक्त अंतिम चरण में होती है जब क्लाइंट को HTTP स्थिति कोड प्राप्त होता है जो '300' के रूप में पहचानता है।

300 त्रुटियों को ठीक करना - सामान्य

पहली बात आपको क्या करना चाहिए एक वेब ब्राउज़र में अपने URL की जांच है। यदि आपको कुछ प्रकार का वेब पेज दिखाई देता है जो आपको एक्शन/विकल्प के लिए प्रेरित करता है, तो आपका यूआरएल खड़ा है, यह प्रक्रिया के लिए वेब सर्वर के लिए पर्याप्त विस्तृत नहीं है।

300 त्रुटियों को ठीक करना - CheckUpDown

आप अपने CheckUpDown अकाउंट इस त्रुटि कभी नहीं देखना चाहिए अगर आप हमें एक शीर्ष-स्तरीय URL (जैसे www.isp.com के रूप में) की जाँच करने दे दी है। यदि यह शीर्ष-स्तरीय यूआरएल के लिए होता है, तो यह अत्यधिक संभावना है कि वेब सर्वर सॉफ़्टवेयर को गलत तरीके से प्रोग्राम किया गया है या कॉन्फ़िगर किया गया है। यदि आपके पास है तो हमें निम्न स्तर के URL (जैसे कि www.isp.com/products/index.html) को चेक पर दिया गया है, तो संभव है कि यह URL वेब ब्राउज़र के माध्यम से भी पहुंच योग्य न हो।

आपको सबसे पहले जो करना चाहिए वह वेब ब्राउज़र में अपना यूआरएल जांचना है। यदि आपको एक समझदार वेब पेज दिखाई देता है, तो यह हमारे सॉफ़्टवेयर में एक दोष इंगित कर सकता है। यदि आप किसी प्रकार का वेब पेज देखते हैं तो आपको आगे की कार्रवाई/विकल्प के लिए संकेत मिलता है, तो आपका यूआरएल हमारे लिए जांचने के लिए उपयुक्त नहीं है क्योंकि हमारी प्रणाली संभवतः इस तरह की पसंद नहीं कर सकती है।

जब भी आप 300 त्रुटियों का सामना करते हैं तो कृपया हमसे सीधे संपर्क करें (ईमेल पसंदीदा)। केवल हम उन्हें आपके लिए हल कर सकते हैं। यदि हमारे सॉफ़्टवेयर में कोई दोष है तो हम इसे ठीक कर देंगे। यदि आपका यूआरएल उपयोग के लिए मूल रूप से अनुपयुक्त है, तो आपको इसे अपने चेकअपडाउन खाते में बदलना होगा ( से 'प्रबंधित करें' बटन पर क्लिक करना)।

उत्तर

0

HTTP 303, क्योंकि इसमें सबसे उपयुक्त फॉर्मूलेशन है - अन्य देखें (302-अस्थायी रूप से और 301 - स्थायी रूप से स्थानांतरित)। इस स्थिति में वास्तव में HTTP 303 प्रतिक्रिया यह सुनिश्चित करने के लिए कि वेब उपयोगकर्ता का ब्राउज़र प्रारंभिक HTTP POST अनुरोध को पुनः सबमिट किए बिना सर्वर प्रतिक्रिया को सुरक्षित रूप से रीफ्रेश कर सकता है।

+1

, 303 एक है कि निश्चित रूप से गलत है। उदाहरण के लिए, यदि आप किसी वार्तालाप संसाधन पर जाते हैं, तो आप नहीं चाहते हैं कि HTTP लाइब्रेरी रीडायरेक्ट के बाद GET को अनुरोध करने के लिए अनुरोध को बदल दे। –

1

संभावित रूप से HTTP 300 "Multiple Choices" क्योंकि यह तकनीकी रूप से एक ही डेटा/दस्तावेज़ है लेकिन कई भाषाओं में उपलब्ध है?

+0

मुझे लगता है कि आप सही हैं। –

+2

वार्ता विफल होने पर सभी विकल्पों को सूचीबद्ध करने वाले दस्तावेज़ के साथ 300 स्थिति कोड का उपयोग करने के लिए उपयोग किया जाना चाहिए। – Gumbo

+0

हां - लेकिन यह नहीं है कि क्या किया जा रहा है (कोड को देख रहे हैं)? यदि भाषा HTTP_ACCEPT_LANGUAGE से स्वत: पता चला है तो ऐसा करें - अन्यथा ऐसी कोई टिप्पणी है जो '// डिफ़ॉल्ट साइट या भाषा के लिए संकेत' दिखाती है ... यह "भाषा के लिए संकेत" बिट था जो मुझे लगता है कि 300 होगा "सही" ... हालांकि, प्रोग्रामिंग में लगभग किसी भी चीज़ के साथ, हमेशा "दाएं" के लिए कई मान होते हैं;) – CD001

1

मुझे लगता है कि सवाल अधिक संबंधित आप क्या हासिल करना चाहते है:

1: आपका सूचकांक पेज आपके आगंतुक के लिए लैंडिंग पृष्ठ होना चाहिए, और आप चाहते हैं कि पेज खोज इंजन द्वारा अनुक्रमित किया।

पेशेवरों: आप अपने सभी आगंतुकों है कि वास्तविक लैंडिंग पृष्ठ से पहले अतिरिक्त जानकारी के होस्ट कर सकते हैं के लिए एक प्रविष्टि पृष्ठ है। हालांकि, इसमें एक विशिष्ट भाषा के लिए सामग्री नहीं होगी।

विपक्ष: आपके पास खोज इंजन पर सभी भाषाओं के लिए कोई सामग्री पृष्ठ नहीं है।

2: वास्तविक अनुवादित पृष्ठ लैंडिंग पृष्ठ होना चाहिए, और यदि संभव हो तो अपने दर्शकों के अनुवाद पेज कि सीधे यदि संभव हो तो है पर पहुंचना चाहिए। रीडायरेक्ट पेज केवल उन विज़िटर के लिए है जो एड्रेसबार में होस्टनाम दर्ज करके सीधे आपकी साइट पर समाप्त हो जाते हैं।

पेशेवरों: आपको हर एकल भाषा है, जो स्कोरिंग और क्लिक होने में मदद करता है के लिए एक से अधिक "लैंडिंग पृष्ठों" है।

विपक्ष: आपके पास एक सामान्य लैंडिंग पृष्ठ नहीं है।

अधिक पेशेवरों और इन दो विकल्पों पर विपक्ष हैं, लेकिन मैं इसके बारे में अभी सोच भी नहीं सकते।

तो विकल्प 1: एक 302 का उपयोग करें क्योंकि आप अभी भी इसे खोज इंडेक्स का हिस्सा बनना चाहते हैं। यदि विकल्प 2: 301 का उपयोग करें क्योंकि आप नहीं चाहते कि वह पृष्ठ अनुक्रमित हो। वैकल्पिक रूप से, भाषा चयन पृष्ठ पर नोंडेक्स का उपयोग करें।

AFAIK, गूगल केवल पर ध्यान देता है 301, 302 और 307 (अस्थायी रखरखाव), और मैं इसे 302 के रूप में सब कुछ पर विचार लगता है (सबसे तार्किक लगता है)। जहां तक ​​ब्राउज़र जाता है, मुझे लगता है कि इससे कोई फर्क नहीं पड़ता। यह कैशिंग को प्रभावित कर सकता है, लेकिन मुझे लगता है कि आजकल वे 3xx प्रतिक्रियाओं को कैशिंग में बहुत आक्रामक हैं।

+0

मैं प्रत्येक भाषा पृष्ठ प्रत्येक भाषा खोज अनुक्रमणिका में अनुक्रमित करना चाहता हूं। (यानी स्पेनिश रिटर्न/es/में खोजें, अंग्रेजी वापसी/एन/में खोजें)। क्या आपको लगता है कि मुझे डिफ़ॉल्ट भाषा के लिए होम पेज होना चाहिए? क्या मुझे rel = canonical का उपयोग करना चाहिए? – jrosell

+0

यदि आप चाहें तो इसके लिए आप कैनोलिक का उपयोग कर सकते हैं, लेकिन जरूरी नहीं। यदि आप हमेशा 301 के साथ आगंतुकों को रीडायरेक्ट करते हैं, तो Google केवल भाषा यूआरएल को अनुक्रमित करेगा। – jishi

+0

क्या आपको लगता है कि सामग्री बातचीत के अनुसार 301 होने का अर्थ है? – jrosell

4

आप एक ही यूआरएल के तहत हर भाषा की सेवा कर सकते हैं और फिर Accept-Language शीर्षलेख की सामग्री-वार्तालाप का उपयोग कर सकते हैं, लेकिन मैं इसकी अनुशंसा नहीं करता।

मैं आपको सुझाव दूंगा कि आपकी वेबसाइट्स रूट यूआरएल पर, आप किसी भाषा उप पृष्ठ (E.g. /en) पर रीडायरेक्ट (303 - अन्य देखें) जारी करते हैं। जब आप ऐसा करते हैं, तो Vary शीर्षलेख के साथ प्रतिक्रिया दें, जो Accept-Language निर्दिष्ट करता है (और Cookie जैसे कोई अन्य प्रासंगिक शीर्षलेख)। इस तरह, किसी भी मध्यस्थ (प्रॉक्सी, कैश) प्रतिक्रिया को कैश करने में सक्षम होंगे। मैं विशेष रूप से एक 301 जारी करता हूं, क्योंकि आप अभी भी रूट यूआरएल को इंगित करने के लिए लिंक चाहते हैं। भाषा-विशिष्ट पृष्ठ पर, मैं रूट यूआरएल में rel="canonical" डालूंगा।

भी देखें इन धागों:

+0

मैं इस 2 लिंक का शोध करूंगा, लेकिन अभी के लिए ... क्या 'प्रत्येक भाषा के लिए स्थान शीर्षलेख' की एक सूची आउटपुट करना संभव है और ब्राउज़र को निर्णय लेने दें? – jrosell

+0

ब्राउज़र पहले से ही तय कर चुका है, इस तरह, जिसमें अनुरोध (प्राथमिकता-भाषा 'शीर्षलेख) में प्राथमिकता सूची भेजी गई थी। 'वेरी: स्वीकार्य-भाषा' प्रतिक्रिया-हेडर निर्दिष्ट करता है कि यह निर्णय का आधार था। – troelskn

+0

क्या आप वाकई एक वेरी हेडर आवश्यक है? मुझे कोई बहुभाषी साइट नहीं दिखाई देती है जो स्वीकार्य-भाषा वेरी हेडर के साथ प्रतिक्रिया देती है। – Jordy

4

गूगल स्थानीय पृष्ठ पर पुनर्निर्देशन के लिए 302 Found उपयोग करता है।

मुझे लगता है कि अगर Google इसका उपयोग करता है तो यह सुरक्षित है ...

हालांकि, यह हमेशा क्या चुना प्रतिक्रिया करते हैं और क्या यह करने के लिए है चाहिए और यह कैशिंग को प्रभावित करता है की जाँच करने के लिए अच्छा है:

http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

सभी विकल्पों की
संबंधित मुद्दे