अनावश्यक HTTP हेडर

HTTP हेडर यह नियंत्रित करने के लिए महत्वपूर्ण हैं कि कैश और ब्राउज़र आपकी सामग्री को कैसे संसाधित करते हैं। लेकिन उनमें से बहुत से गलत तरीके से या अर्थहीन रूप से उपयोग किए जाते हैं, पेज लोडिंग के महत्वपूर्ण क्षण में अतिरिक्त संसाधन खर्च करते हैं, और वे आपके अनुसार काम नहीं कर सकते हैं। सर्वोत्तम प्रथाओं के बारे में लेखों की एक श्रृंखला में, हम पहले अनावश्यक शीर्षकों को देखेंगे।

अधिकांश डेवलपर्स महत्वपूर्ण और उपयोगी HTTP हेडर के बारे में जानते हैं। सबसे प्रसिद्ध Content-Type और Content-Length , ये लगभग सार्वभौमिक हेडर हैं। लेकिन हाल ही में, Content-Security-Policy बढ़ाने के लिए Content-Security-Policy और Strict-Transport-Security जैसे हेडर का उपयोग किया गया है, और प्रदर्शन में सुधार के लिए Link rel=preload को Link rel=preload किया गया है। ब्राउज़रों में व्यापक समर्थन के बावजूद, केवल कुछ ही उनका उपयोग करते हैं।

इसी समय, कई बेहद लोकप्रिय सुर्खियां हैं जो आम तौर पर नई नहीं हैं और बहुत उपयोगी नहीं हैं। हम इसे Google द्वारा संचालित और तेजी से प्रायोजित HTTP HTTP आर्काइव की मदद से साबित कर सकते हैं, जो हर महीने 500,000 साइटों को डाउनलोड करता है, जो WebPageTest का उपयोग करता है और BigQuery को परिणाम अपलोड करता है।

HTTP संग्रह के अनुसार यहां 30 सबसे लोकप्रिय प्रतिक्रिया शीर्षलेख हैं (संग्रह में प्रत्येक डोमेन की संख्या के आधार पर), और उनमें से प्रत्येक की उपयोगिता का अनुमानित अनुमान:

हैडर	अनुरोध	डोमेन	स्थिति
तिथि	48779277	535,621	प्रोटोकॉल की आवश्यकता है
सामग्री प्रकार	47185627	533,636	आमतौर पर ब्राउज़र द्वारा आवश्यक
सर्वर	43057807	519,663	ऐच्छिक
सामग्री-लंबाई	42388435	519,118	उपयोगी
अंतिम संशोधित	34424562	480,294	उपयोगी
कैश-नियंत्रण	36490878	412,943	उपयोगी
ETag	23620444	412,370	उपयोगी
सामग्री एन्कोडिंग	16194121	409,159	संकुचित सामग्री के लिए आवश्यक है
समय सीमा समाप्त	29869228	360,311	ऐच्छिक
एक्स संचालित-दर	4883204	211,409	ऐच्छिक
pragma	7641647	188,784	ऐच्छिक
एक्स-फ्रेम विकल्प	3670032	105,846	ऐच्छिक
पहुंच-नियंत्रण-अनुमति देने के मूल	11335681	103,596	उपयोगी
एक्स-सामग्री-प्रकार-विकल्प	11071560	94590	उपयोगी
लिंक	1212329	87,475	उपयोगी
आयु	7401415	59,242	उपयोगी
एक्स-कैश	5275343	56,889	ऐच्छिक
एक्स-XSS सुरक्षा	9773906	51810	उपयोगी
सख्त-परिवहन-सुरक्षा	4259121	51,283	उपयोगी
के माध्यम से	4020117	47,102	ऐच्छिक
पी 3 पी	8282840	44308	ऐच्छिक
उम्मीद-सीटी	2685280	40,465	उपयोगी
सामग्री-भाषा	334,081	37,927	यकीनन
एक्स-aspnet-संस्करण	676,128	33,473	ऐच्छिक
पहुंच-नियंत्रण-अनुमति दें-क्रेडेंशियल	2804382	30,346	उपयोगी
एक्स रोबोट-टैग	179,177	24,911	ब्राउज़रों के लिए कोई फर्क नहीं पड़ता
X-UA- संगत	489,056	24,811	ऐच्छिक
पहुंच-नियंत्रण-अनुमति देते हैं-तरीकों	1626129	20,791	उपयोगी
पहुंच-नियंत्रण-अनुमति देते हैं-हेडर	1205735	19120	उपयोगी

आइए वैकल्पिक हेडर देखें, हमें उनकी आवश्यकता क्यों नहीं है, और इसके बारे में क्या करना है।

वैनिटी (सर्वर, एक्स-पावर्ड-बाय)

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

Server: apache
X-Powered-By: PHP/5.1.1
Via: 1.1 varnish, 1.1 squid

RFC7231 आपको सर्वर प्रतिक्रिया में सर्वर हेडर को शामिल करने की अनुमति देता है, जो उस सर्वर पर विशिष्ट सॉफ़्टवेयर को इंगित करता है जो सामग्री वितरित करने के लिए उपयोग किया जाता है। ज्यादातर अक्सर यह "अपाचे" या "नग्नेक्स" जैसी स्ट्रिंग होती है। हालांकि शीर्षक की अनुमति है, यह वैकल्पिक है और विशेष रूप से डेवलपर्स या अंतिम उपयोगकर्ताओं के लिए मूल्यवान नहीं है। हालाँकि, आज यह इंटरनेट पर तीसरा सबसे लोकप्रिय HTTP सर्वर हैडर है।

X-Powered-By सबसे लोकप्रिय शीर्षक है जो किसी भी मानक द्वारा परिभाषित नहीं है और इसका एक समान उद्देश्य है: यह आमतौर पर एप्लिकेशन प्लेटफॉर्म को इंगित करता है जिस पर सर्वर चल रहा है। सबसे लोकप्रिय उत्तरों में "ASP.net", "PHP" और "एक्सप्रेस" शामिल हैं। फिर, यह कोई ठोस लाभ नहीं लाता है और बस जगह लेता है।

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

पदावनत मानक (P3P, समय सीमा, एक्स-फ़्रेम-विकल्प, X-UA- संगत)

हेडर्स की एक और श्रेणी है जो वास्तव में ब्राउज़र में एक प्रभाव का कारण बनती है, लेकिन (पहले से ही) इस प्रभाव को प्राप्त करने का सबसे अच्छा तरीका नहीं है।

P3P: cp="this is not a p3p policy"
Expires: Thu, 01 Dec 1994 16:00:00 GMT
X-Frame-Options: SAMEORIGIN
X-UA-Compatible: IE=edge

P3P एक मजेदार छोटी चीज है। मुझे नहीं पता था कि यह क्या था। यहां तक ​​कि मजेदार, P3P हेडर की सबसे आम सामग्री में से एक है "यह P3P नियम नहीं है।" अच्छा, यह है या नहीं?

यहाँ, कहानी मशीन-पठनीय गोपनीयता नियमों को मानकीकृत करने के प्रयास में वापस आती है । ब्राउज़रों में डेटा प्रदर्शित करने को लेकर असहमति थी, और केवल एक ब्राउज़र ने इस हेडर के लिए समर्थन लागू किया - इंटरनेट एक्सप्लोरर। लेकिन इसमें भी, पी 3 पी का उपयोगकर्ता के लिए कोई दृश्य प्रभाव नहीं था; उन्हें बस फ्रेम में तीसरे पक्ष के कुकीज़ तक पहुंच की अनुमति देने के लिए उपस्थित होना था। कुछ साइटें P3P गैर-अनुपालन नियमों को भी निर्धारित करती हैं, जैसा कि ऊपर दिए गए उदाहरण में है, हालांकि ऐसा करना अत्यधिक संदिग्ध है ।

यह कहने की आवश्यकता नहीं है कि तृतीय-पक्ष कुकीज़ को पढ़ना आमतौर पर एक बुरा विचार है, इसलिए यदि आप नहीं करते हैं, तो आपको P3P हेडर सेट करने की आवश्यकता नहीं है!

Expires बस अविश्वसनीय रूप से लोकप्रिय है, यह मानते हुए कि Cache-Control 20 से अधिक वर्षों के लिए Expires से बेहतर है। यदि Cache-Control हेडर में max-age निर्देश होता है, तो उसी प्रतिक्रिया में किसी भी समय Expires हेडर को अनदेखा कर दिया जाता है। लेकिन बड़ी संख्या में साइटें इन दोनों हेडर को सेट करती हैं, और Expires सबसे अधिक बार Thu, 01 Dec 1994 16: 00: 00 GMT सेट करते हैं Thu, 01 Dec 1994 16: 00: 00 GMT , ताकि सामग्री कैश्ड न हो। बेशक, विनिर्देशों से तारीख की नकल करना सबसे आसान है।



लेकिन ऐसा करने की कोई जरूरत नहीं है। यदि आपके पास अतीत से एक तिथि के साथ एक समय Expires , तो बस इसे बदलें:

Cache-Control: no-store, private

( no-store एक बहुत सख्त निर्देश है कि लगातार स्टोरेज के लिए सामग्री न लिखें, इसलिए आप बेहतर प्रदर्शन के लिए no-cache पसंद कर सकते हैं, उदाहरण के लिए, किसी ब्राउज़र में पीछे / आगे या सोते हुए टैब को फिर से शुरू करने के लिए)

कुछ साइट सत्यापन उपकरण आपको 'SAMEORIGIN' के मान के साथ X-Frame-Options हेडर जोड़ने की सलाह देंगे। यह ब्राउज़रों को बताता है कि आप किसी अन्य साइट पर एक फ्रेम में सामग्री भेजने से इनकार करते हैं: एक नियम के रूप में, यह क्लिकजैकिंग के खिलाफ एक अच्छा बचाव है। लेकिन समान प्रभाव को एक और हेडर के साथ अधिक सुसंगत समर्थन और अधिक विश्वसनीय व्यवहार के साथ प्राप्त किया जा सकता है:

Content-Security-Policy: frame-ancestors 'self'

यहां एक अतिरिक्त लाभ है, क्योंकि आपको अभी भी अन्य कारणों (बाद में उनके बारे में अधिक) के लिए सीएसपी हेडर देना होगा। शायद, हमारे समय में, आप X-Frame-Options बिना कर सकते हैं।

अंत में, IE9 में वापस, Microsoft ने एक "संगतता मोड" पेश किया जो IE8 या IE7 इंजन का उपयोग करके पृष्ठ को प्रदान करता है। सामान्य मोड में भी, ब्राउज़र ने सोचा कि उचित रेंडरिंग के लिए इंजन के पुराने संस्करण की आवश्यकता हो सकती है। ये आंकड़े हमेशा सही ढंग से काम नहीं करते थे, और डेवलपर्स X-UA-Compatible हेडर या मेटा टैग का उपयोग करके उन्हें ओवरराइड कर सकते थे। वास्तव में, यह बूटस्ट्रैप जैसे कई ढांचे का एक मानक हिस्सा बन गया है। अब यह शीर्षक व्यावहारिक रूप से बेकार है: यह समझने वाले ब्राउज़रों का अनुपात बहुत छोटा है। और यदि आप सक्रिय रूप से साइट का समर्थन करते हैं, तो यह बहुत संभावना नहीं है कि यह उन प्रौद्योगिकियों का उपयोग करता है जो संगतता मोड लॉन्च करेंगे।

डीबगिंग डेटा (X-ASPNet-Version, X-Cache)

कुछ मायनों में, यह आश्चर्यजनक है कि कुछ सबसे लोकप्रिय शीर्षकों का उल्लेख किसी भी मानक में बिल्कुल भी नहीं किया गया है। अनिवार्य रूप से, इसका मतलब यह है कि हजारों वेबसाइटें किसी न किसी तरह एक निश्चित शीर्षक का उपयोग करने के लिए सहमत हैं।

X-Cache: HIT
X-Request-ID: 45a336c7-1bd5-4a06-9647-c5aab6d5facf
X-ASPNet-Version: 3.2.32
X-AMZN-RequestID: 0d6e39e2-4ecb-11e8-9c2d-fa7ae01bbebc

वास्तव में, डेवलपर्स द्वारा इन "अज्ञात" शीर्षकों का आविष्कार नहीं किया गया था। आमतौर पर, ये कुछ सर्वर फ्रेमवर्क, विशिष्ट आपूर्तिकर्ताओं के सॉफ्टवेयर या सेवाओं के उपयोग की कलाकृतियां हैं (उदाहरण के लिए, अंतिम हेडर AWS के लिए विशिष्ट है)।

X-Cache हेडर फास्ट-(और अन्य सीडीएन) जोड़ता है, साथ ही अन्य विशिष्ट हेडर जैसे X-Cache-Hits और X-Served-By । डिबगिंग सक्षम होने पर, अधिक जोड़ा जाता है, उदाहरण के लिए, Fastly-Debug-Path और Fastly-Debug-TTL ।

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

गलतफहमी (प्रगति)

मुझे उम्मीद नहीं थी कि 2018 में मुझे Pragma हेडर का उल्लेख करना होगा, लेकिन HTTP आर्काइव के अनुसार, यह अभी भी शीर्ष (11 वें स्थान) पर है। यह केवल 1997 में अप्रचलित वापस घोषित नहीं किया गया था, लेकिन इसे कभी भी एक प्रतिक्रिया हेडर के रूप में कल्पना नहीं की गई थी, लेकिन केवल अनुरोध के हिस्से के रूप में।

Pragma: no-cache

फिर भी, यह व्यापक रूप से प्रतिक्रिया हैडर के रूप में उपयोग किया जाता है कि कुछ ब्राउज़र इस संदर्भ में भी इसे पहचानते हैं। लेकिन आज लगभग शून्य मौका है कि कोई Pragma को उत्तर के संदर्भ में समझता है, लेकिन Cache-Control को नहीं समझता है। यदि आप कैशिंग को अक्षम करना चाहते हैं, तो आपको Cache-Control: no-store, private आवश्यकता है Cache-Control: no-store, private ।

गैर-ब्राउज़र (एक्स-रोबोट-टैग)

हमारे शीर्ष 30 में से एक शीर्षक ब्राउज़र के लिए एक शीर्षक नहीं है। X-Robots-Tag क्रॉलर के लिए डिज़ाइन किया गया है जैसे Google बॉट या बिंग। चूंकि यह एक ब्राउज़र के लिए बेकार है, आप केवल क्रॉलर से अनुरोध करने के लिए ऐसा जवाब सेट कर सकते हैं। या आप तय करते हैं कि यह परीक्षण को कठिन बनाता है या खोज इंजन के उपयोग की शर्तों का उल्लंघन करता है।

कीड़े

अंत में, यह साधारण गलतियों के सम्माननीय उल्लेख के साथ समाप्त होने के लायक है। Host हेडर अनुरोध में समझ में आता है, लेकिन यदि यह प्रतिक्रिया में दिखाई देता है, तो संभवतः आपका सर्वर सही तरीके से कॉन्फ़िगर नहीं किया गया है (और मैं यह जानना चाहूंगा कि कैसे)। हालाँकि, HTTP संग्रह में 68 डोमेन उनकी प्रतिक्रियाओं में Host हेडर लौटाते हैं।

एक किनारे CDN सर्वर पर हेडर निकालना

सौभाग्य से, यदि आपकी साइट हमारे साथ तेजी से चलती है, तो वीसीएल का उपयोग करके हेडर को हटाना बहुत सरल है। यदि आप डिबगिंग के लिए विकास टीम को वास्तव में उपयोगी रखना चाहते हैं, लेकिन इसे आम जनता से छिपाते हैं, तो यह कुकीज़ या आने वाले HTTP हेडर का उपयोग करके आसानी से किया जा सकता है:

unset resp.http.Server;
unset resp.http.X-Powered-By;
unset resp.http.X-Generator;

if (!req.http.Cookie:debug && !req.http.Debug) {
unset resp.http.X-Amzn-RequestID;
unset resp.http.X-Cache;
}

अगले लेख में मैं वास्तव में आवश्यक शीर्षकों के लिए सर्वोत्तम अभ्यासों और सीडीएन एज सर्वर पर उन्हें सक्रिय करने के तरीके के बारे में बात करूंगा।