🐡 🚔 👝 दो-सामना REQUEST_URI या सही HTTP / 1.1 सर्वर की तलाश में 📸 ⚕️ 👂🏿

क्या आप जानते हैं कि PHP में Apache mod_rewrite और $ _SERVER ["REQUEST_URI"] में % {REQUEST_URI} का अंतर है?

क्या आप www के उपसर्ग के साथ डोमेन से 301 का सही अग्रेषण कर सकते हैं या इसे Apache स्तर पर .htaccess में कर सकते हैं?

आखिरी सवाल के लिए, मैं अभी भी एक समाधान की पेशकश नहीं कर सकता। इसका कारण HTTP / 1.1 प्रोटोकॉल है, जिसे मैंने "साइकिल का आविष्कार" (साइट के लिए कोर बनाया) के बारे में अधिक विस्तार से अध्ययन करना था।

यह "होस्ट:" अनुरोध के HTTP हेडर के बारे में है। कुछ शर्तों के तहत, कुछ भी हो सकता है, और सर्वर को HTTP / 1.1 के अनुसार इसे पूरी तरह से अनदेखा करना चाहिए। अधिकांश डेवलपर्स इस क्षेत्र के मूल्य का उपयोग करते हैं, उदाहरण के लिए, एसईओ-अनुकूलन के लिए। आगे देखते हुए, मैं कहूंगा कि एक अतिरिक्त प्रॉक्सी (उदाहरण के लिए, nginx) इस समस्या को हल करेगा।

सर्वरों के गलत व्यवहार को समझने के लिए, मैंने हैबर कंपनियों की साइटों पर पुनरावृति करने का फैसला किया। एक दर्जन साइटों के लिए, उन्होंने इसे मैन्युअल रूप से किया, और फिर पता चला कि कुछ साइटें गलत अनुरोधों का जवाब "सही ढंग से" देती हैं। उसके बाद, एक छोटी परीक्षण उपयोगिता लिखी गई, जिसने परीक्षण पैटर्न और साइटों की संख्या को बढ़ाने की अनुमति दी।

HTTP / 1.1 में REQUEST_URI क्या छुपाता है?

सिद्धांत

HTTP / 1.0

मैं HTTP / 1.0 प्रोटोकॉल के साथ शुरू करूँगा, जिसका वर्णन RfC1945 www.w3.org/Protocols/rfc1945/rfc1945 में किया गया है और इसकी अवधि मई 1996 है। वांछित पृष्ठ प्राप्त करने के लिए, सर्वर से कनेक्ट करना और एक पंक्ति भेजना पर्याप्त था:

  GET /path/to/resource.html HTTP / 1.0

प्रॉक्सी सर्वर को एक्सेस करते समय, निरपेक्ष पथ का उपयोग करना आवश्यक था, लेकिन पूरा पता:

  Http://domain.name/path/to/resource.html HTTP / 1.0 प्राप्त करें

यह सब खंड 5.1.2 "अनुरोध-यूआरआई" में वर्णित है।

मेजबान उपस्थिति

एक सर्वर के लिए एक साथ कई डोमेन नामों की सेवा करने में सक्षम होने के लिए, प्रोटोकॉल रचनाकारों ने "होस्ट:" अनुरोध हेडर को जोड़ा, जिसमें वह डोमेन होना चाहिए जिसे एक्सेस किया जा रहा है। हालाँकि यह शीर्ष लेख HTTP / 1.0 मानक का हिस्सा नहीं है, लेकिन यह कुछ सर्वरों और ग्राहकों द्वारा समर्थित हो गया है। उदाहरण के लिए, wget HTTP / 1.0 पर अनुरोध भेजता है, लेकिन "होस्ट:" जोड़ता है।

HTTP / 1.1

जून 1999 (चौदह साल पहले) में, HTTP / 1.1 प्रोटोकॉल दिखाई दिया, जिसका वर्णन RfC2616 www.w3.org/Protocols/rfc2616/rfc2616.html में है । धारा 14.23 में, नए प्रोटोकॉल में "होस्ट" फ़ील्ड को शामिल करने के लिए प्रत्येक अनुरोध शीर्षलेख की आवश्यकता होती है:

एक क्लाइंट सभी HTTP / 1.1 अनुरोध संदेशों में एक होस्ट हेडर फ़ील्ड शामिल करना चाहिए। यदि अनुरोधित URI में अनुरोध की जा रही सेवा के लिए एक इंटरनेट होस्ट नाम शामिल नहीं है, तो होस्ट हेडर फ़ील्ड MUST को खाली मान के साथ दिया जाना चाहिए।

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

HTTP के भावी संस्करणों में सभी अनुरोधों में निरपेक्षता के लिए संक्रमण की अनुमति देने के लिए, सभी HTTP / 1.1 सर्वर अनुरोधों में निरपेक्ष रूप को स्वीकार करते हैं, भले ही HTTP / 1.1 क्लाइंट केवल प्रॉक्सी के अनुरोधों में उन्हें उत्पन्न करेंगे।

मैं इस तथ्य पर आपका ध्यान आकर्षित करता हूं कि यह पूर्ण पते पर जाना चाहिए था (निरपेक्षता, उदाहरण के लिए, http : //www.w3.org/pub/WWW/TheProject.html ), इसलिए ग्राहकों को केवल पूर्ण पथ (abs_path, उदाहरण के लिए, / pub ) का उपयोग करने की आवश्यकता नहीं है /WWW/TheProject.html )। इसके अलावा, सर्वर को स्पष्ट रूप से निरपेक्षता के साथ ग्राहकों से अनुरोधों का जवाब देने की क्षमता की आवश्यकता होती है, इसलिए, इस मामले में आपत्ति है कि ग्राहक का अनुरोध सही नहीं है, मैं तुरंत इसे बाहर कर देता हूं, क्योंकि "ग्राहक हमेशा सही होता है"।

HTTP / 1.1 में होस्ट करें

अनुरोध-यूआरआई में परिवर्तन हानिरहित लग सकता है, लेकिन धारा 5.2 में एक महत्वपूर्ण आवश्यकता है: “यदि अनुरोध-यूआरआई एक निरपेक्ष है, तो मेजबान अनुरोध-यूआरआई का हिस्सा है। अनुरोध में किसी भी होस्ट हेडर फ़ील्ड मान को अनदेखा किया जाना चाहिए। ”यानी, अनुरोध की व्याख्या

  Http://domain.name/path/to/resource.html HTTP / 1.1 प्राप्त करें
 होस्ट: anytext

अनुरोध से मेल खाना चाहिए

  GET /path/to/resource.html HTTP / 1.1
 होस्ट: domain.name

क्या आप "होस्ट:" को अनदेखा करते हैं जब निरपेक्षता के साथ क्वेरी की जाती है?

% {REQUEST_URI} और $ _SERVER ["REQUEST_URI"]

Mod_rewrite के लिए प्रलेखन निम्नलिखित कहता है:

THE_REQUEST
ब्राउज़र द्वारा सर्वर को भेजी गई पूर्ण HTTP अनुरोध रेखा (उदाहरण के लिए, "GET /index.html HTTP / 1.1")। इसमें ब्राउज़र द्वारा भेजा गया कोई अतिरिक्त हेडर शामिल नहीं है। नीचे दिए गए अधिकांश अन्य चरों के विपरीत इस मान को अनसैप्ड (डिकोड) नहीं किया गया है।

REQUEST_URI
अनुरोधित URI का पथ घटक, जैसे "/index.html"। यह विशेष रूप से क्वेरी स्ट्रिंग को बाहर करता है जो कि QUERY_STRING नामक अपने स्वयं के चर के रूप में उपलब्ध है।

अर्थात,% {REQUEST_URI} में हमेशा एक पूर्ण मार्ग होगा और कभी भी पूर्ण पता नहीं होगा।

यदि उपयोगकर्ता निम्नलिखित अनुरोध भेजता है, तो mod_rewrite का उपयोग किए बिना डोमेन में "www" जोड़ने के मानक एसईओ कार्य का प्रयास करें:

  Http://domain.name/path/to/resource.html HTTP / 1.1 प्राप्त करें
 होस्ट: www.domain.name

लेख की शुरुआत में मैंने Apache mod_rewrite में $ {REQUEST_URI} और PHP में $ _SERVER ["REQUEST_URI"] के अंतर के बारे में पूछा, इसलिए मैं PHP के लिए प्रलेखन से एक अंश दे दूंगा:

REQUEST_URI
यूआरआई जो इस पेज को एक्सेस करने के लिए दिया गया था; उदाहरण के लिए, '/index.html'।

इसे कहीं कॉन्फ़िगर किया जा सकता है, लेकिन मेरे लिए PHP / 5.3.13 पूर्ण पते के साथ अनुरोध किए जाने पर पूर्ण रिटर्न देता है।

अभ्यास

आइए अब विचार करें कि जब आप वास्तविक सर्वर को क्वेरी करते हैं तो क्या होता है। मैंने हाबरा कंपनियों के पेज से साइटों के पते ले लिए (सूची में वहां बदलाव हुआ, मैंने इसे पिछले सप्ताह के अंत में लिया था)। मैंने Node.JS पर एक छोटी स्क्रिप्ट को स्केच किया है, जिसमें http_check फ़ंक्शन एकल अनुरोध भेजता है, और full_http_check कुछ टेम्पलेट्स के अनुसार कुछ सर्वरों के लिए कई अनुरोध उत्पन्न करता है।

स्क्रिप्ट कोड

var net = require('net'); var default_result = function(title) { if (title) { return {'title': 'title', 'step': 'step', 'host': 'host', 'request': 'request', 'header': 'header', 'full_response': 'full_response', 'response': 'response', 'server': 'server', 'length': 'length', 'location': 'location', 'error': 'error'}; } else { return {'title': '', 'step': '', 'host': '', 'request': '', 'header': '', 'full_response': '', 'response': '', 'server': '', 'length': '', 'location': '', 'error': ''}; } }; var format_result = function(result) { return '' + result['title'].toString() + '\t' + result['step'] + '\t' + result['host'] + '\t' + result['request'].toString() + '\t' + result['header'].toString() + '\t' + result['response'].toString() + '\t' + result['server'].toString() + '\t' + result['length'].toString() + '\t' + result['error'].toString() + '\t' + result['location'].toString() + '\t' + result['full_response'].toString(); }; var http_check = function(title, step, host, req, host_hdr) { var host_header = host_hdr || ''; var result = default_result(false); result['title'] = title; result['step'] = step; result['host'] = host; result['request'] = req; result['header'] = host_header; var dat = ''; var client = net.connect({port: 80, host: host}, function() { //'connect' listener client.on('data', function (data) { dat = dat + data; var lines = dat.toString().split('\r\n'); result['full_response'] = JSON.stringify(dat.toString().split('\r\n\r\n')[0]); result['response'] = lines[0] || false; if (lines[0].substring(0, 5) == 'HTTP/') { var i = 1; while (lines[i] != '') { var title = lines[i].match(/^([^:]+:)\s(.+)$/); if (title[1] == 'Location:') { result['location'] = title[2]; } else if (title[1] == 'Server:') { result['server'] = title[2]; } else if (title[1] == 'Content-Length:') { result['length'] = title[2]; } i++; } if (dat.indexOf('\r\n\r\n') >= 0) { client.end(); client.destroy(); } } else { client.end(); client.destroy(); } }); client.on('end', function () { console.log('client disconnected'); }); client.on('error', function (error) { console.log('ERROR: ' + error.toString()); }); client.on('timeout', function () { console.log('Timeout'); }); client.on('close', function (had_error) { result['error'] = result['error'] || had_error || ''; console.log(format_result(result)); }); client.write(req + '\r\n'); host_hdr && client.write('Host: ' + host_hdr + '\r\n'); client.write('\r\n'); }); }; var full_http_check = function(title, url) { var parts = url.match(/^http:\/\/([^\/]+)(.+)$/); // 1 // GET /path/to/resource.html HTTP/1.1 // Host: domain.name http_check(title, '01', parts[1], 'GET ' + parts[2] + ' HTTP/1.1', parts[1]); // 2 // GET http://domain.name/path/to/resource.html HTTP/1.1 // Host: domain.name http_check(title, '02', parts[1], 'GET http://' + parts[1] + parts[2] + ' HTTP/1.1', parts[1]); // 3 // GET /path/to/resource.html HTTP/1.0 http_check(title, '03', parts[1], 'GET ' + parts[2] + ' HTTP/1.0', ''); // 4 // GET /path/to/resource.html HTTP/1.0 // Host: domain.name http_check(title, '04', parts[1], 'GET ' + parts[2] + ' HTTP/1.0', parts[1]); // 5 // GET http://domain.name/path/to/resource.html HTTP/1.0 http_check(title, '05', parts[1], 'GET http://' + parts[1] + parts[2] + ' HTTP/1.0', ''); // 6 // GET http://domain.name/path/to/resource.html HTTP/1.0 // Host: domain.name http_check(title, '06', parts[1], 'GET http://' + parts[1] + parts[2] + ' HTTP/1.0', parts[1]); // 7 // GET http://domain.name/path/to/resource.html HTTP/1.1 // Host: void.domain.name http_check(title, '07', parts[1], 'GET http://' + parts[1] + parts[2] + ' HTTP/1.1', 'void.' + parts[1]); // 8 // GET http://domain.name/path/to/resource.html HTTP/1.1 // Host: local.fake http_check(title, '08', parts[1], 'GET http://' + parts[1] + parts[2] + ' HTTP/1.1', 'local.fake'); // 9 // GET http://domain.name/path/to/resource.html HTTP/1.1 // Host: l-IjFN=fiG(w+J2p:#.{92!m`d^? http_check(title, '09', parts[1], 'GET http://' + parts[1] + parts[2] + ' HTTP/1.1', 'l-IjFN=fiG(w+J2p:#.{92!m`d^?'); // 10 // GET http://fake.domain.name/path/to/resource.html HTTP/1.1 // Host: domain.name http_check(title, '10', parts[1], 'GET http://fake.' + parts[1] + parts[2] + ' HTTP/1.1', parts[1]); // 11 // GET http://local.fake/path/to/resource.html HTTP/1.1 // Host: domain.name http_check(title, '11', parts[1], 'GET http://local.fake' + parts[2] + ' HTTP/1.1', parts[1]); // 12 // GET http://l-IjFN=fiG(w+J2p:#.{92!m`d^?/path/to/resource.html HTTP/1.1 // Host: domain.name http_check(title, '12', parts[1], 'GET http://l-IjFN=fiG(w+J2p:#.{92!m`d^?' + parts[2] + ' HTTP/1.1', parts[1]); // 13 // GET http://local.fake/path/to/resource.html HTTP/1.1 // Host: void.domain.name http_check(title, '13', parts[1], 'GET http://local.fake' + parts[2] + ' HTTP/1.1', 'void.' + parts[1]); // 14 // GET habr://domain.name/path/to/resource.html HTTP/1.1 // Host: domain.name http_check(title, '14', parts[1], 'GET habr://' + parts[1] + parts[2] + ' HTTP/1.1', parts[1]); // 15 // GET habr://void.domain.name/path/to/resource.html HTTP/1.1 // Host: domain.name http_check(title, '15', parts[1], 'GET habr://void.' + parts[1] + parts[2] + ' HTTP/1.1', parts[1]); // 16 // GET habr://local.fake/path/to/resource.html HTTP/1.1 // Host: domain.name http_check(title, '16', parts[1], 'GET habr://local.fake' + parts[2] + ' HTTP/1.1', parts[1]); // 17 // GET habr://l-IjFN=fiG(w+J2p:#.{92!m`d^?/path/to/resource.html HTTP/1.1 // Host: domain.name http_check(title, '17', parts[1], 'GET habr://l-IjFN=fiG(w+J2p:#.{92!m`d^?' + parts[2] + ' HTTP/1.1', parts[1]); // 18 // GET habr://l-IjFN=fiG(w+J2p:#.{92!m`d^?/path/to/resource.html HTTP/1.1 // Host: local.fake http_check(title, '18', parts[1], 'GET habr://l-IjFN=fiG(w+J2p:#.{92!m`d^?' + parts[2] + ' HTTP/1.1', 'local.fake'); }; console.log(format_result(default_result(true))); /* http_check('IBM Fake', 'www.ibm.com', 'GET ttp://com/midmarket/ru/ru/ HTTP/1.1', 'ibm'); full_http_check('IBM', 'http://www.ibm.com/midmarket/ru/ru/'); */ full_http_check('', 'http://company.yandex.ru/about/main/'); full_http_check('JetBrains', 'http://www.jetbrains.com/products.html'); full_http_check('Box Overview', 'http://7del.net/texts/galaxy-note.html'); full_http_check('KolibriOS Project Team', 'http://kolibrios.org/en/download.htm'); full_http_check('Opera Software ASA', 'http://www.opera.com/about'); full_http_check('Apps4All', 'http://apps4all.ru/news/apple/apple-ios-7-beta.html'); full_http_check('', 'http://nordavind.ru/node/207'); full_http_check('Mail.Ru Group', 'http://corp.mail.ru/about/'); full_http_check('Microsoft', 'http://windows.microsoft.com/ru-RU/windows/home'); full_http_check('Zfort Group', 'http://www.zfort.com.ua/company/about/'); full_http_check('IBM', 'http://www.ibm.com/contact/ru/ru/'); full_http_check('UIDG', 'http://uidesign.ru/about/'); full_http_check('Intel', 'http://www.intel.ru/content/www/ru/ru/company-overview/company-overview.html'); full_http_check('Rusonyx', 'http://www.rusonyx.ru/company/reasons/'); full_http_check('', 'http://www.mosigra.ru/page/about/'); full_http_check('DevConf', 'http://devconf.ru/about/'); full_http_check('e-Legion Ltd.', 'http://www.e-legion.ru/contacts/'); full_http_check('Badoo', 'http://corp.badoo.com/company/'); full_http_check(' ()', 'http://mobile.beeline.ru/msk/setup/index.wbp');

अब प्रत्येक टेम्पलेट और साइटों की प्रतिक्रिया पर करीब से नज़र डालते हैं।

अनुरोध 1

निरपेक्ष पथ और सही होस्ट हेडर सहित सबसे सामान्य HTTP / 1.1 अनुरोध विकल्प। किसी भी सर्वर को सही ढंग से इसका जवाब देना चाहिए, अर्थात हम "HTTP / 1.1 200 OK" की प्रतीक्षा कर रहे हैं।

  GET /path/to/resource.html HTTP / 1.1
 होस्ट: domain.name

सभी सर्वर "HTTP / 1.1 200 ठीक है।" निम्नलिखित "सर्वर" प्रतिक्रिया हेडर के लिए मूल्यों की तालिका है:

कंपनी	सर्वर शीर्षक:
Apps4All	nginx / 1.0.15
badoo	nginx
बॉक्स अवलोकन	nginx / 1.2.1
DevConf	nginx / 1.0.15
ई-लीजन लिमिटेड	nginx / 1.0.5
आईबीएम	IBM_HTTP_Server
इंटेल	Microsoft-IIS / 7.5
जेटब्रेन्स	nginx
KolibriOS प्रोजेक्ट टीम	lighttpd / 1.4.32
Mail.Ru Group	nginx / 1.2.5
माइक्रोसॉफ्ट	Microsoft-IIS / 7.5
ओपेरा सॉफ्टवेयर ASA	nginx
Rusonyx	nginx
UIDG	अपाचे
Zfort समूह	nginx / 1.4.1
विम्पेलकॉम (बीलाइन)	Microsoft-IIS / 7.5
Mosigra	nginx / 1.4.1
Nordavind	nginx / 1.0.4
Yandex	nginx / 1.2.1

निवेदन २

पहले प्रकार के अनुरोधों का एक प्रकार, लेकिन पूर्ण पथ के बजाय, पूरा पता निर्दिष्ट करें।

  Http://domain.name/path/to/resource.html HTTP / 1.1 प्राप्त करें
 होस्ट: domain.name

इस अनुरोध के जवाब में, सभी सर्वरों ने फिर से एकमत दिखाया। "लाइट" अनुरोध करता है कि प्रत्येक सर्वर पार्स करना जानता है।

निवेदन ३

"होस्ट:" के बिना, एक पूर्ण पथ के साथ HTTP / 1.0 के लिए अनुरोध करें। "HTTP / 1.0 200 ठीक होना चाहिए।"

  GET /path/to/resource.html HTTP / 1.0

तीसरे अनुरोध पर, सर्वर "बौछार"। और एक भी HTTP / 1.0 200 ठीक प्रतिक्रिया नहीं है।

कंपनी	सर्वर प्रतिक्रिया
Apps4All	HTTP / 1.1 301 स्थायी रूप से चला गया
badoo	HTTP / 1.1 302 अस्थायी रूप से चला गया
बॉक्स अवलोकन	HTTP / 1.1 200 ठीक है
DevConf	HTTP / 1.1 404 नहीं मिला
ई-लीजन लिमिटेड	HTTP / 1.1 301 स्थायी रूप से चला गया
आईबीएम	HTTP / 1.1 200 ठीक है
इंटेल	HTTP / 1.0 400 खराब अनुरोध
जेटब्रेन्स	HTTP / 1.1 301 स्थायी रूप से चला गया
KolibriOS प्रोजेक्ट टीम	HTTP / 1.0 404 नहीं मिला
Mail.Ru Group	HTTP / 1.1 200 ठीक है
माइक्रोसॉफ्ट	HTTP / 1.1 200 ठीक है
ओपेरा सॉफ्टवेयर ASA	HTTP / 1.1 404 नहीं मिला
Rusonyx	HTTP / 1.1 301 स्थायी रूप से चला गया
UIDG	HTTP / 1.1 404 नहीं मिला
Zfort समूह	HTTP / 1.1 404 नहीं मिला
विम्पेलकॉम (बीलाइन)	HTTP / 1.1 302 रीडायरेक्ट
Mosigra	HTTP / 1.1 404 नहीं मिला
Nordavind	HTTP / 1.1 200 ठीक है
Yandex	HTTP / 1.1 404 नहीं मिला

निवेदन ४

पिछला अनुरोध, लेकिन "होस्ट:" जोड़ें। यह केवल प्रोटोकॉल संस्करण में पहले अनुरोध से अलग है।

  GET /path/to/resource.html HTTP / 1.0
 होस्ट: domain.name

होस्ट ने सर्वर पर बहुत सकारात्मक तरीके से काम किया - सभी के पास "200 ओके" प्रतिक्रिया थी, लेकिन केवल निम्नलिखित में HTTP / 1.0: Intel और KolibriOS प्रोजेक्ट टीम थी।

निवेदन ५

"होस्ट:" के बिना, पूर्ण पते के साथ HTTP / 1.0 के लिए अनुरोध करें। यह पढ़ने के लिए बहुत अच्छा होगा "HTTP / 1.0 200 ठीक है।"

  Http://domain.name/path/to/resource.html HTTP / 1.0 प्राप्त करें

तस्वीर पिछली क्वेरी के परिणामों के साथ पूरी तरह से सुसंगत है, लेकिन यहां ई-लीजन लिमिटेड है। जारी "HTTP / 1.1 500 आंतरिक सर्वर त्रुटि"।

निवेदन ६

पिछला अनुरोध, लेकिन "होस्ट:" जोड़ें। यह केवल प्रोटोकॉल संस्करण में दूसरे अनुरोध से अलग है।

  Http://domain.name/path/to/resource.html HTTP / 1.0 प्राप्त करें
 होस्ट: domain.name

परिणाम पूरी तरह से चौथी क्वेरी के साथ मेल खाते हैं, अर्थात्, "होस्ट:" ई-लीजन सर्वर पर एक आंतरिक त्रुटि तय की है

निवेदन 7

एक पूर्ण पते के साथ दूसरे अनुरोध का एक संस्करण, लेकिन "होस्ट:" में हम एक बिना किसी सबडोमेन के लिखते हैं। अनुरोध बिल्कुल सही है, इसलिए सर्वर को "HTTP / 1.1 200 ठीक है" के साथ जवाब देना चाहिए।

  Http://domain.name/path/to/resource.html HTTP / 1.1 प्राप्त करें
 होस्ट: void.domain.name

निवेदन 8

अब "होस्ट:" के रूप में, हम एक अविशिष्ट डोमेन निर्दिष्ट करेंगे। अनुरोध में कुछ भी नहीं बदला है, लेकिन कुछ सर्वर अब इसे पसंद नहीं कर सकते हैं।

  Http://domain.name/path/to/resource.html HTTP / 1.1 प्राप्त करें
 होस्ट: स्थानीय

निवेदन ९

"होस्ट:" हेडर को पूरी तरह से नजरअंदाज किया जाना चाहिए, इसलिए हम एक मनमाना पाठ लिखेंगे जो बहुत से पासवर्ड ईर्ष्या करेंगे। मानक के अनुसार, हम "HTTP / 1.1 200 ठीक है।"

  Http://domain.name/path/to/resource.html HTTP / 1.1 प्राप्त करें
 होस्ट: l-IjFN = fiG (w + J2p: #? {92! M`d ^)

सर्वर 7-9 ने अनुरोधों का समान रूप से जवाब दिया:

कंपनी	सर्वर प्रतिक्रिया	सर्वर शीर्षक:
Apps4All	HTTP / 1.1 200 ठीक है	nginx / 1.0.15
badoo	HTTP / 1.1 200 ठीक है	nginx
बॉक्स अवलोकन	HTTP / 1.1 200 ठीक है	nginx / 1.2.1
DevConf	HTTP / 1.1 500 आंतरिक सर्वर त्रुटि	nginx / 1.0.15
ई-लीजन लिमिटेड	HTTP / 1.1 500 आंतरिक सर्वर त्रुटि	nginx / 1.0.5
आईबीएम	HTTP / 1.1 200 ठीक है	IBM_HTTP_Server
इंटेल	HTTP / 1.0 400 खराब अनुरोध	AkamaiGHost
जेटब्रेन्स	HTTP / 1.1 200 ठीक है	nginx
KolibriOS प्रोजेक्ट टीम	HTTP / 1.1 200 ठीक है	lighttpd / 1.4.32
Mail.Ru Group	HTTP / 1.1 200 ठीक है	nginx / 1.2.5
माइक्रोसॉफ्ट	HTTP / 1.1 200 ठीक है	Microsoft-IIS / 7.5
ओपेरा सॉफ्टवेयर ASA	HTTP / 1.1 200 ठीक है	nginx
Rusonyx	HTTP / 1.1 200 ठीक है	nginx
UIDG	HTTP / 1.1 200 ठीक है	अपाचे
Zfort समूह	HTTP / 1.1 200 ठीक है	nginx / 1.4.1
विम्पेलकॉम (बीलाइन)	HTTP / 1.1 200 ठीक है	Microsoft-IIS / 7.5
Mosigra	HTTP / 1.1 200 ठीक है	nginx / 1.4.1
Nordavind	HTTP / 1.1 200 ठीक है	nginx / 1.0.4
Yandex	HTTP / 1.1 200 ठीक है	nginx / 1.2.1

अनुरोध १०

गलत अनुरोधों में से पहला। हम सही "होस्ट:" भेजेंगे, लेकिन पूरे पते में हम एक नक्सटेड सबडोमेन जोड़ देंगे।

  Http://fake.domain.name/path/to/resource.html HTTP / 1.1 प्राप्त करें
 होस्ट: domain.name

चूंकि त्रुटियों के साथ प्रश्न शुरू हुए, इसलिए परिणाम डरावना नहीं होना चाहिए।

कंपनी	सर्वर प्रतिक्रिया
Apps4All	HTTP / 1.1 301 स्थायी रूप से चला गया
badoo	HTTP / 1.1 301 स्थायी रूप से चला गया
बॉक्स अवलोकन	HTTP / 1.1 200 ठीक है
DevConf	HTTP / 1.1 404 नहीं मिला
ई-लीजन लिमिटेड	HTTP / 1.1 301 स्थायी रूप से चला गया
आईबीएम	HTTP / 1.1 200 ठीक है
इंटेल	HTTP / 1.1 200 ठीक है
जेटब्रेन्स	HTTP / 1.1 301 स्थायी रूप से चला गया
KolibriOS प्रोजेक्ट टीम	HTTP / 1.1 404 नहीं मिला
Mail.Ru Group	HTTP / 1.1 200 ठीक है
माइक्रोसॉफ्ट	HTTP / 1.1 200 ठीक है
ओपेरा सॉफ्टवेयर ASA	HTTP / 1.1 404 नहीं मिला
Rusonyx	HTTP / 1.1 301 स्थायी रूप से चला गया
UIDG	HTTP / 1.1 404 नहीं मिला
Zfort समूह	HTTP / 1.1 404 नहीं मिला
विम्पेलकॉम (बीलाइन)	HTTP / 1.1 302 रीडायरेक्ट
Mosigra	HTTP / 1.1 301 स्थायी रूप से चला गया
Nordavind	HTTP / 1.1 200 ठीक है
Yandex	HTTP / 1.1 404 नहीं मिला

लगभग एक तिहाई सर्वरों ने सही रास्ता (पुनर्निर्देशित) सुझाने की कोशिश में समय बर्बाद नहीं किया। दुर्भाग्य से, कई सर्वर केवल मुख्य पृष्ठ पर रीडायरेक्ट करते हैं।

निवेदन ११

अब एक गैर-मौजूद डोमेन भेजने का प्रयास करें।

  Http: //local.fake/path/to/resource.html HTTP / 1.1 प्राप्त करें
 होस्ट: domain.name

यहां परिणाम पिछले अनुरोध के साथ पूरी तरह से मेल खाते हैं, लेकिन "एचटीटीपी / 1.1 301 मूव्ड परमानेंट" के बजाय मोसिगरा ने पहले ही "HTTP / 1.1 404 Not Found" जारी कर दिया।

अनुरोध 12

लेकिन क्या मनमाना पाठ एक डोमेन के रूप में काम करेगा?

  GET http: // l-IjFN = fiG (w + J2p: #। {92! M`d ^? / Path / to / resource.html HTTP / 1.1
 होस्ट: domain.name

"HTTP / 1.1 200 OK" प्रतिक्रिया इंटेल और ओपेरा सॉफ्टवेयर एएसए से आई है। IBM और मोसिग्रा ने HTTP / 1.1 404 Not Found को वापस कर दिया है। बाकी सभी ने 404 बैड रिक्वेस्ट लिखी, जिसमें बिना हेडर वाला हिस्सा था (HTTP / 1.0 में संभावित विकल्प)।

निवेदन १३

ग्यारहवें अनुरोध की एक प्रति, लेकिन "होस्ट:" के रूप में एक उपडोमेन के साथ भी। यह शायद ही अन्य गलत संयोजनों की जांच करने के लिए समझ में आता है।

  Http: //local.fake/path/to/resource.html HTTP / 1.1 प्राप्त करें
 होस्ट: void.domain.name

परिणाम भी अनुरोध 11 की एक प्रति बन गए, लेकिन इंटेल ने आत्मसमर्पण कर दिया और "HTTP / 1.0 400 खराब अनुरोध" वापस कर दिया।

निवेदन १४

दूसरा अनुरोध, लेकिन हम पूर्ण पते को निर्दिष्ट करते समय एक गैर-मौजूद प्रोटोकॉल का उपयोग करेंगे। पहले से ही कोई गलती होनी चाहिए।

  Hbr प्राप्त करें: //domain.name/path/to/resource.html HTTP / 1.1
 होस्ट: domain.name

यह पता चला कि काफी साइटें HABR प्रोटोकॉल को स्वीकार करती हैं:

कंपनी	सर्वर प्रतिक्रिया
Apps4All	HTTP / 1.1 200 ठीक है
badoo	HTTP / 1.1 200 ठीक है
बॉक्स अवलोकन	HTTP / 1.1 200 ठीक है
DevConf	HTTP / 1.1 200 ठीक है
ई-लीजन लिमिटेड	HTTP / 1.1 200 ठीक है
आईबीएम	HTTP / 1.1 200 ठीक है
इंटेल	HTTP / 1.0 400 खराब अनुरोध
जेटब्रेन्स	HTTP / 1.1 200 ठीक है
KolibriOS प्रोजेक्ट टीम	HTTP / 1.1 301 स्थायी रूप से चला गया
Mail.Ru Group	HTTP / 1.1 200 ठीक है
माइक्रोसॉफ्ट	HTTP / 1.1 400 खराब अनुरोध
ओपेरा सॉफ्टवेयर ASA	HTTP / 1.1 400 BAD_REQUEST
Rusonyx	HTTP / 1.1 200 ठीक है
UIDG	HTTP / 1.1 200 ठीक है
Zfort समूह	HTTP / 1.1 200 ठीक है
विम्पेलकॉम (बीलाइन)	HTTP / 1.1 400 खराब अनुरोध
Mosigra	HTTP / 1.1 400 BAD_REQUEST
Nordavind	HTTP / 1.1 200 ठीक है
Yandex	HTTP / 1.1 200 ठीक है

अनुरोध 15

आइए अंत में सर्वर के प्रतिरोध को तोड़ने और पिछले अनुरोध भेजने का प्रयास करें, लेकिन गलत उपडोमेन के साथ।

  प्राप्त करें: //void.domain.name/path/to/resource.html HTTP / 1.1
 होस्ट: domain.name

परिणाम दसवीं क्वेरी के समान हैं, लेकिन इसमें भी परिवर्तन हैं:

कंपनी	अनुरोध १०	अनुरोध 15
Apps4All	HTTP / 1.1 301 स्थायी रूप से चला गया	HTTP / 1.1 301 स्थायी रूप से चला गया
badoo	HTTP / 1.1 301 स्थायी रूप से चला गया	HTTP / 1.1 301 स्थायी रूप से चला गया
बॉक्स अवलोकन	HTTP / 1.1 200 ठीक है	HTTP / 1.1 200 ठीक है
DevConf	HTTP / 1.1 404 नहीं मिला	HTTP / 1.1 404 नहीं मिला
ई-लीजन लिमिटेड	HTTP / 1.1 301 स्थायी रूप से चला गया	HTTP / 1.1 301 स्थायी रूप से चला गया
आईबीएम	HTTP / 1.1 200 ठीक है	HTTP / 1.1 200 ठीक है
इंटेल	HTTP / 1.1 200 ठीक है	HTTP / 1.0 400 खराब अनुरोध
जेटब्रेन्स	HTTP / 1.1 301 स्थायी रूप से चला गया	HTTP / 1.1 301 स्थायी रूप से चला गया
KolibriOS प्रोजेक्ट टीम	HTTP / 1.1 404 नहीं मिला	HTTP / 1.1 301 स्थायी रूप से चला गया
Mail.Ru Group	HTTP / 1.1 200 ठीक है	HTTP / 1.1 200 ठीक है
माइक्रोसॉफ्ट	HTTP / 1.1 200 ठीक है	HTTP / 1.1 400 खराब अनुरोध
ओपेरा सॉफ्टवेयर ASA	HTTP / 1.1 404 नहीं मिला	HTTP / 1.1 400 BAD_REQUEST
Rusonyx	HTTP / 1.1 301 स्थायी रूप से चला गया	HTTP / 1.1 301 स्थायी रूप से चला गया
UIDG	HTTP / 1.1 404 नहीं मिला	HTTP / 1.1 404 नहीं मिला
Zfort समूह	HTTP / 1.1 404 नहीं मिला	HTTP / 1.1 404 नहीं मिला
विम्पेलकॉम (बीलाइन)	HTTP / 1.1 302 रीडायरेक्ट	HTTP / 1.1 400 खराब अनुरोध
Mosigra	HTTP / 1.1 301 स्थायी रूप से चला गया	HTTP / 1.1 400 BAD_REQUEST
Nordavind	HTTP / 1.1 200 ठीक है	HTTP / 1.1 200 ठीक है
Yandex	HTTP / 1.1 404 नहीं मिला	HTTP / 1.1 404 नहीं मिला

निवेदन १६

आइए एक मनमाने डोमेन का उपयोग करने का प्रयास करें।

  GET habr: //local.fake/path/to/resource.html HTTP / 1.1
 होस्ट: domain.name

परिणाम पिछली क्वेरी से मेल खाते थे।

निवेदन १ 17

और तीसरी बार हम डोमेन को मनमाने ढंग से टेक्स्ट से बदलने की कोशिश करेंगे।

  GET habr: // l-IjFN = fiG (w + J2p: #। {92 & M`d ^? / Path / to / resource.html HTTP / 1.1
 होस्ट: domain.name

पहले से ही सर्वर से एक भी सकारात्मक प्रतिक्रिया नहीं है। 12 अनुरोधों की तुलना में, निम्नलिखित साइटों में परिवर्तन हैं:

कंपनी	अनुरोध 12	निवेदन १ 17
इंटेल	HTTP / 1.1 200 ठीक है	HTTP / 1.0 400 खराब अनुरोध
KolibriOS प्रोजेक्ट टीम	HTTP / 1.1 400 खराब अनुरोध	HTTP / 1.1 301 स्थायी रूप से चला गया
ओपेरा सॉफ्टवेयर ASA	HTTP / 1.1 200 ठीक है	HTTP / 1.1 400 BAD_REQUEST
Mosigra	HTTP / 1.1 404 नहीं मिला	HTTP / 1.1 400 BAD_REQUEST

निवेदन १ 18

अब चलो सही "होस्ट:" हेडर से छुटकारा पाने की कोशिश करें।

  GET habr: // l-IjFN = fiG (w + J2p: #। {92 & M`d ^? / Path / to / resource.html HTTP / 1.1
 होस्ट: स्थानीय

पिछले परिणाम से सिर्फ एक बदलाव - कोलीब्रिज़ प्रोजेक्ट टीम सर्वर ने "HTTP / 1.1 301 मूव्ड परमानेंटली" के बजाय "HTTP / 1.1 404 Not Found" को वापस करना शुरू कर दिया।

अनुरोध एन

यदि आप किसी अन्य क्वेरी विकल्प को आज़माना चाहते हैं, तो लिखें। और आप इसे स्वयं कर सकते हैं।

निष्कर्ष

आइए कुछ परिणामों को संक्षेप में प्रस्तुत करने का प्रयास करें। लगभग सभी समीक्षित सर्वरों ने HTTP / 1.1 अनुरोधों का सही उत्तर दिया। अपवाद DevConf, e-Legion Ltd. और इंटेल। पहले दो उपयोग nginx, इसलिए समस्या इसके कॉन्फ़िगरेशन में सबसे अधिक संभावना है। इंटेल AkamaiGHost का उपयोग करता है, जो या तो अनुचित रूप से कॉन्फ़िगर किया गया है या HTTP / 1.1 का खराब समर्थन करता है। मैं मानता हूं कि परीक्षणों को सही ढंग से पारित करने के कारणों में से एक नगनेक्स है (यह 19 में से 14 सर्वरों द्वारा उपयोग किया गया था)। संस्करणों में अंतर के कारण, UIDG के लिए nginx / 1.0.10 और nginx / 1.4.1 की एक श्रृंखला की खोज की गई थी।

आपको लगता है कि सब कुछ सरल है? अपाचे को एसईओ के साथ स्थापित करने की कोशिश करें ताकि यह सही ढंग से एक गलत "होस्ट:" के साथ अनुरोधों को संसाधित करे और यह केवल क्वेरी स्ट्रिंग में पूर्ण पते पर आधारित हो।

"गलत" सही प्रश्नों का व्यावहारिक अर्थ क्या है? मुझे संदेह है कि किसी भी भेद्यता का पता लगाना संभव होगा। लेकिन वास्तव में, लगभग पंद्रह वर्षों में किसी ने नहीं सीखा कि सही HTTP / 1.1 सर्वर कैसे बनाया जाए?

PS अपाचे mod_rewrite और $ _SERVER ["REQUEST_URI"] PHP में % {REQUEST_URI} के बीच अंतर को याद रखें।

UPD1:

निवेदन १ ९

AEP की सलाह पर , मैंने दूसरा अनुरोध किया, लेकिन मेजबान को एक और शून्य बाइट और कुछ स्ट्रिंग जोड़ा। यह इस बात पर निर्भर करता था कि सर्वर शून्य बाइट के साथ होस्ट को कितनी अच्छी तरह अनदेखा करेगा।

  Http://domain.name/path/to/resource.html HTTP / 1.1 प्राप्त करें
 होस्ट: domain.name {शून्य बाइट} fake_and_void

स्क्रिप्ट में निम्नलिखित टेम्पलेट जोड़े:

 http_check(title, '19', parts[1], 'GET http://' + parts[1] + parts[2] + ' HTTP/1.1', parts[1] + '\0fake_and_void_text');

सभी सर्वर ने आईबीएम, ओपेरा सॉफ्टवेयर एएसए और मोसिगरा को छोड़कर "HTTP / 1.1 400 बैड रिक्वेस्ट" लौटा दी।
जब मैंने अनुरोध पर एक शून्य बाइट जोड़ने की कोशिश की, तो आईबीएम और ओपेरा सॉफ्टवेयर को छोड़कर सभी ने 400 त्रुटि की सूचना दी।

दो-सामना REQUEST_URI या सही HTTP / 1.1 सर्वर की तलाश में