$ _REQUEST, $ _GET और $ _POST में से कौन सा सबसे तेज है?

Question

इनमें से कौन सा कोड तेज होगा?

$temp = $_REQUEST['s'];

या

if (isset($_GET['s'])) {
  $temp = $_GET['s'];
}
else {
  $temp = $_POST['s'];
}

Comments

एक तीसरा मामला है, y'know। !isset($_REQUEST['s'])।

— फ्रांज

यह कितना महत्वपूर्ण है कि अन्य लोग आपके कोड को स्पष्ट रूप से समझें? POST और GET स्पष्ट हैं, जबकि REQUEST विभिन्न स्रोतों से आ सकता है। मुझे लगता है कि REQUEST, POST के बाद से दक्षता नगण्य है, और GET के सुपरग्लोबल्स हमेशा प्रत्येक अनुरोध के लिए लोड किए जाते हैं।

— केविन

Answer 1

$_REQUESTडिफ़ॉल्ट रूप से, की सामग्री है $_GET, $_POSTऔर $_COOKIE।

लेकिन यह केवल एक डिफ़ॉल्ट है, जो निर्भर करता है variables_order; और सुनिश्चित नहीं है कि आप कुकीज़ के साथ काम करना चाहते हैं।

अगर मुझे चुनना था, तो मैं शायद उपयोग नहीं करूंगा $_REQUEST, और मैं चुनूंगा $_GETया $_POST- मेरे आवेदन के आधार पर क्या करना चाहिए (यानी एक या दूसरे, लेकिन दोनों नहीं) : आम तौर पर बोल:

• $_GETजब कोई आपके एप्लिकेशन से डेटा का अनुरोध कर रहा हो, तो आपको उसका उपयोग करना चाहिए ।
• और अगर आप का उपयोग करना चाहिए $_POSTजब कोई जोर दे रहा है (डालने या अद्यतन, या हटाने) डेटा के लिए अपने आवेदन।

किसी भी तरह से, प्रदर्शन के बारे में बहुत अंतर नहीं होगा: अंतर आपकी भाषा के बाकी हिस्सों की तुलना में नगण्य होगा।

Comments

आदर्श रूप से, आपको हमेशा $ _REQUEST का उपयोग करने में सक्षम होना चाहिए। लेकिन निश्चित रूप से यह एक आदर्श दुनिया है।

— टायलर कार्टर

$ _REQUEST $ _POST और $ _GET का सीधे उपयोग करने की तुलना में माना जाता है (या कम से कम उपयोग किया जाता है) अधिक महंगा है।

— डारेल ब्रॉगडन

+1 प्रदर्शन अंतर की अवधारणा के नगण्य होने और रखरखाव के परिप्रेक्ष्य के अधिक महत्वपूर्ण होने के कारण: $ _GET और $ _POST इस तरह से अर्थ व्यक्त करते हैं कि $ _REQUEST नहीं हो सकता।

— जॉन क्रैम

$ _REQUEST का उपयोग XSS / XSRF का कारण नहीं बनता है। XSS / XSRF की बारीकियों को न समझने से XSS / XSRF का कारण बनता है। जब तक आप टोकन के साथ कम करते हैं, कोई समस्या नहीं है और आपको $ _REQUEST (आपके सभी चर एक सुपरग्लोबल में हैं) का उपयोग करने का लाभ मिलता है। मैं वास्तव में $ _REQUEST को अन्य सुपरग्लोब के आधार पर 'वैरिएबल_ऑर्डर' के कारण उपयोग करने से पहले पुनर्निर्माण करता हूं। मैं $ _COOKIE प्रक्रिया करता हूं, फिर $ _GET, फिर $ _POST। इस तरह POST var की सर्वोच्च प्राथमिकता है और कुकी var सबसे कम मिलते हैं, जो मुझे कई बग्स (जैसे Adobe Flash और मैजिक कोट्स) को स्पष्ट रूप से ठीक करने की अनुमति देता है।

— क्यूबिकलसॉफ्ट

इसके नाम में, Get = get से, Post = post से

— क्रोधी

Answer 2

पोस्ट बनाम जी.एस.टी.

1) GET और POST दोनों एक सरणी बनाते हैं (उदाहरण के लिए array (key => value, key2 => value2, key3 => value3, ...))। यह सरणी कुंजी / मान जोड़े रखती है, जहाँ कुंजियाँ प्रपत्र नियंत्रण के नाम हैं और मान उपयोगकर्ता के इनपुट डेटा हैं।

2) GET और POST दोनों को $ _GET और $ _POST के रूप में माना जाता है। ये सुपरग्लोबल्स हैं, जिसका अर्थ है कि वे हमेशा पहुंच योग्य होते हैं, गुंजाइश की परवाह किए बिना - और आप उन्हें किसी भी फ़ंक्शन, वर्ग या फ़ाइल से कुछ विशेष करने के बिना उपयोग कर सकते हैं।

3) $ _GET URL मापदंडों के माध्यम से वर्तमान स्क्रिप्ट को पारित चर का एक सरणी है।

4) $ _POST HTTP POST विधि के माध्यम से वर्तमान स्क्रिप्ट को पारित चर का एक सरणी है।

GET का उपयोग कब करें?

GET विधि के साथ एक फॉर्म से भेजी गई जानकारी सभी को दिखाई देती है (सभी परिवर्तनशील नाम और मान URL में प्रदर्शित होते हैं)। GET में सूचना भेजने की मात्रा की सीमा भी है। सीमा लगभग 2000 वर्ण है। हालाँकि, क्योंकि चरों को URL में प्रदर्शित किया जाता है, इसलिए पृष्ठ को बुकमार्क करना संभव है। यह कुछ मामलों में उपयोगी हो सकता है।

गैर-संवेदनशील डेटा भेजने के लिए GET का उपयोग किया जा सकता है।

नोट: पासवर्ड या अन्य संवेदनशील जानकारी भेजने के लिए कभी भी उपयोग नहीं किया जाना चाहिए!

POST का उपयोग कब करें?

POST विधि के साथ एक फॉर्म से भेजी गई जानकारी दूसरों के लिए अदृश्य है (सभी नाम / मान HTTP अनुरोध के निकाय के भीतर एम्बेडेड हैं) और भेजने की जानकारी की मात्रा पर कोई सीमा नहीं है।

इसके अलावा POST उन्नत कार्यक्षमता का समर्थन करता है जैसे कि सर्वर पर फाइल अपलोड करते समय मल्टी-पार्ट बाइनरी इनपुट के लिए समर्थन।

हालाँकि, क्योंकि चरों को URL में प्रदर्शित नहीं किया गया है, इसलिए पृष्ठ को बुकमार्क करना संभव नहीं है।

Comments

कृपया REQUEST के बारे में भी कुछ जोड़ें।

— ब्लैक माम्बा

$ _REQUEST के बारे में क्या?

— आमिर कालिमी

Answer 3

$ _GET क्वेरिस्ट्रिंग, या आपके URL से चर प्राप्त करता है।>

$ _POST एक POST विधि से चर को पुनः प्राप्त करता है, जैसे (आमतौर पर) रूप।

$ _REQUEST $ _GET और $ _POST का विलय है जहाँ $ _POST $ _GET से आगे निकल जाता है। मान्यताओं के लिए स्व-रीफ्रेंशियल रूपों पर $ _REQUEST का उपयोग करना अच्छा है।

Comments

+1 यह मूल रूप से वही है जो मुझे सिखाया गया था। अन्य उत्तरों की तरह तकनीकी नहीं, लेकिन याद रखने में आसान ( GETक्वेरी स्ट्रिंग से, POSTफॉर्म सबमिशन से)।

— jp2code

Answer 4

मैं उपयोग करने का सुझाव था $_POSTऔर $_GETस्पष्ट रूप से।

$ _REQUEST का उपयोग करना वैसे भी उचित साइट डिज़ाइन के साथ अनावश्यक होना चाहिए, और यह कुछ डाउनसाइड्स के साथ आता है जैसे कि आप आसान CSRF/XSSहमलों के लिए खुला छोड़ देते हैं और अन्य मूर्खताएं जो URL में डेटा संग्रहीत करने से आती हैं।

गति अंतर दोनों ही तरह से न्यूनतम होना चाहिए।

Answer 5

REQUEST का उपयोग करें। किसी को भी इस तरह के एक सरल ऑपरेशन की गति की परवाह नहीं है, और यह बहुत क्लीनर कोड है।

Comments

अच्छा जवाब, इस चेतावनी के साथ कि कई स्थितियों में एक या एक का उपयोग करने के बजाय स्थिति के आधार पर एक GST या POST उठाया जाना चाहिए।

— ceejayoz

आप सही हैं कि किसी को परवाह नहीं है, लेकिन मेरे विचार $_REQUESTसे गलत निष्कर्ष है। मेरा जवाब देखिए।

— फ्रांज

क्यों $ _REQUEST का उपयोग $ _GET या $ _POST की तुलना में क्लीनर है? $ _REQUEST दृश्य के पीछे एक ही तर्क करता है और GET या POST लेने से आपको अधिक नियंत्रण मिलता है।

— जे ज़ेंग

दावा है कि _REQUEST को अधिक स्वच्छ रहने की आवश्यकता है।

यदि आप उपयोगकर्ता को URL की प्रतिलिपि बनाने में सक्षम होना चाहते हैं और एक ही ऑपरेशन अर्थात (यह URL 'google.com/q=searchWord' जैसा दिखाई दे रहा है) पोस्ट करने के लिए GET का उपयोग करने की सलाह देंगे, जबकि POST का उपयोग किसी वेबसाइट पर डेटा पोस्ट करने के लिए किया जाना चाहिए यह केवल एक बार ही डाला जाना चाहिए, या बहुत सारा डेटा सक्रिय है और उपयोगकर्ता को डेटाबेस में डेटा डालने, जैसे लॉगिन करने में सक्षम नहीं होना चाहिए

— डीन मेहान

Answer 6

चिंता मत करो। लेकिन आप अभी भी दूसरा समाधान (प्लस वे चर मौजूदा में से कोई भी के लिए एक अतिरिक्त जांच), उपयोग करें, क्योंकि वहाँ के साथ सुरक्षा मुद्दों कर रहे हैं चाहिए $_REQUEST(क्योंकि $_GETऔर $_POSTहै कि सरणी के लिए एकमात्र स्रोत नहीं हैं)।

$_REQUESTकल के साथ समस्याओं के बारे में एक पोस्ट थी, मुझे विश्वास है। मुझे इसे खोजने दो।

संपादित करें : ओह ठीक है, सीधे एक पोस्ट नहीं, लेकिन यहाँ वैसे भी है: http://kuza55.blogspot.com/2006/03/request-variable-fixation.html

Answer 7

if (isset($_GET['s'])) {
  $temp = $_GET['s'];
}
else {
  $temp = $_POST['s'];
}

इसका उपयोग करें क्योंकि यह सुरक्षित है और यह ध्यान देने योग्य गति अंतर नहीं करेगा

Comments

बुरा समाधान बिलकुल नहीं। इससे जुड़ी सुरक्षा खामियों का ध्यान रखता है, $_REQUESTलेकिन फिर भी उसी स्क्रिप्ट को किसी भी तरह से एक्सेस करने की अनुमति देता है (मेरे मामले में, एक ही स्क्रिप्ट का उपयोग अलग-अलग 'कार्यों' के साथ किया जाता है और कुछ बार $ _GET ठीक होगा, लेकिन दूसरी बार मुझे $ की आवश्यकता होगी _POST डेटा को छिपाने / सुरक्षित करने के लिए)।

— Xandor

Answer 8

एक हैकर के रूप में कुछ सुरक्षा चिंताएँ शामिल हैं जो एक कुकी सेट कर सकती हैं जो $ _POST या $ _GET मान को ओवरराइड करेगी। यदि आप संवेदनशील डेटा संभालते हैं, तो मैं $ _REQUEST का उपयोग करने की अनुशंसा नहीं करूंगा। - Xandor

आपको किसी मामले पर $_GETवैकल्पिक उपयोग नहीं किया जा सकता है $_POST।

कब ??

• जब आप कोई फ़ाइल अपलोड करना चाहते हैं।
• जब आपको url में डेटा नहीं दिखाना है।

GETजानकारी भेजने की मात्रा पर सीमा भी है। सीमा लगभग 2000 वर्ण है।

जब आप डेटा का उपयोग करके पुनः प्राप्त नहीं कर सकते हैं तो अन्य चीज़ों के कुछ मामले हैं $_POST

कब ?

• जब URL में डेटा पास किया जाता है।

रेस्ट सर्विस के लिए

`GET` - Provides a read only access to a resource.

`PUT` - Used to create a new resource.

उपयोग करने के लिए कुछ भी गलत नहीं है $_REQUEST।

लेकिन ऐसा करने का तरीका $ _SERVER ['REQUEST_METHOD'] को स्पष्ट रूप से जांचना है, GET के लिए $ _POST के खाली होने पर निर्भर नहीं होना चाहिए।

Comments

$_SERVER['REQUEST_METHOD']यह जांचने के लिए कि क्या स्क्रिप्ट को किसी एक के साथ बुलाया जाएगा, का उपयोग करने की अच्छी सलाह । लेकिन कहने के लिए कुछ भी गलत $_REQUESTनहीं है 100% सच नहीं है। एक हैकर के रूप में कुछ सुरक्षा चिंताएँ शामिल हैं जो एक कुकी सेट कर सकती हैं जो $ _POST या $ _GET मान को ओवरराइड करेगी। यदि आप संवेदनशील डेटा संभालते हैं, तो मैं उपयोग करने की सलाह नहीं दूंगा $_REQUEST।

— Xandor

मैंने अपने उत्तर में आपकी टिप्पणी जोड़ दी है, यह आपको धन्यवाद देने में मदद करता है

— पार्थ चावड़ा

Answer 9

$ _GET क्वेरिस्ट्रिंग, या आपके URL से चर प्राप्त करता है।>

$ _POST एक POST विधि से चर को पुनः प्राप्त करता है, जैसे (आमतौर पर) रूप।

$ _REQUEST $ _GET और $ _POST का विलय है जहाँ $ _POST $ _GET से आगे निकल जाता है। मान्यताओं के लिए स्व-रीफ्रेंशियल रूपों पर $ _REQUEST का उपयोग करना अच्छा है।

Comments

ओवरराइडिंग निर्भर करता है request_orderऔर इसमें कुकी मान भी हो सकते हैं, यही वजह है कि यह बहुत विश्वसनीय और न ही उपयोगी सुविधा है।

— जेक

Answer 10

मैं दूसरी विधि का उपयोग करूंगा क्योंकि यह अधिक स्पष्ट है। अन्यथा आप नहीं जानते कि चर कहां से आ रहे हैं।

आपको वैसे भी GET और POST दोनों की जांच करने की आवश्यकता क्यों है? निश्चित रूप से एक या दूसरे का उपयोग केवल अधिक समझ में आता है।

Comments

मैंने इसे पहले भी देखा है, GETकेवल एक आइटम (जैसे इसे स्थानांतरित करने के लिए) और POSTउनमें से कई के लिए (चेकबॉक्स के साथ एक रूप ...) का उपयोग किया जा रहा है।

— फ्रांज

Answer 11

मैं केवल कभी _GET या _POST का उपयोग करता हूं। मैं नियंत्रण रखना पसंद करता हूं।

ओपी में कोड के टुकड़े के बारे में मुझे जो पसंद नहीं है वह यह है कि वे उस जानकारी को छोड़ देते हैं जिस पर HTTP विधि का उपयोग किया गया था। और इनपुट सैनिटाइजेशन के लिए यह जानकारी महत्वपूर्ण है।

उदाहरण के लिए, यदि कोई स्क्रिप्ट उस फ़ॉर्म के डेटा को स्वीकार करती है जिसे DB में दर्ज किया जाना है, तो फॉर्म में POST का बेहतर उपयोग हुआ ( केवल भ्रामक कार्यों के लिए GET का उपयोग करें )। लेकिन अगर स्क्रिप्ट GET विधि के माध्यम से इनपुट डेटा प्राप्त करती है तो इसे (सामान्य रूप से) अस्वीकार कर दिया जाना चाहिए। मेरे लिए, इस तरह की स्थिति त्रुटि लॉग के लिए एक सुरक्षा उल्लंघन लिखने के लिए वारंट हो सकती है क्योंकि यह एक संकेत है कि कोई व्यक्ति कुछ पर कोशिश कर रहा है।

ओपी में कोड के टुकड़े के साथ, यह स्वच्छता संभव नहीं होगा।

Comments

वास्तव में, यह एक छोटा सा पेज लिखने के लिए सरल है, जो आप एक पेज पर पोस्ट करना चाहते हैं। इसलिए जब तक आप भेजे जाने वाले हेडर पर भरोसा नहीं करते हैं, तब तक पोस्ट वेरिएंट्स वेरिएंट पाने के मुकाबले ज्यादा सुरक्षित नहीं होते हैं। मुझे लगता है कि स्पष्ट रूप $_POSTसे सबसे बड़ा फायदा यह है कि सर्च इंजन क्रॉलर्स को ऐसा कुछ करने से रोका जाए: thedailywtf.com/Articles/WellIntentioned-Destruction.aspx

— Duroth

मैंने कहा इसके विपरीत कुछ नहीं। मैंने जो कहा वह यह था कि अगर HTML फॉर्म POST का उपयोग करता है और स्क्रिप्ट को संभालने वाला इसे GET के माध्यम से फॉर्म का डेटा प्राप्त करता है, तो स्क्रिप्ट इसके बारे में जानना चाहती है और उस तथ्य को टॉस नहीं करना चाहती है, जैसा कि कोबरा के उदाहरण दोनों करते हैं। (Btw:

Answer 12

मैं उपयोग करूंगा $_POST, और $_GETक्योंकि $_REQUESTउनकी सामग्री से अलग प्रभाव नहीं पड़ता है variables_order।
कब इस्तेमाल करना है $_POSTऔर $_GETइस पर निर्भर करता है कि किस तरह के ऑपरेशन को अंजाम दिया जा रहा है। एक ऑपरेशन जो सर्वर से हैंडल किए गए डेटा को एक पोस्ट अनुरोध के माध्यम से किया जाना चाहिए, जबकि अन्य संचालन जीईटी अनुरोध के माध्यम से किया जाना चाहिए। एक उदाहरण बनाने के लिए, एक ऑपरेशन जो एक उपयोगकर्ता खाते को हटाता है, उसे उपयोगकर्ता द्वारा किसी लिंक पर क्लिक करने के बाद सीधे निष्पादित नहीं किया जाना चाहिए, जबकि एक छवि देखने के लिए एक लिंक के माध्यम से किया जा सकता है।

Answer 13

मैं इसका उपयोग करता हूं,

$request = (count($_REQUEST) > 1)?$_REQUEST:$_GET;

यह कथन मान्य करता है कि यदि $ _REQUEST में एक से अधिक पैरामीटर हैं ($ _REQUEST में पहला पैरामीटर अनुरोध uri होगा, जिसका उपयोग आवश्यकता पड़ने पर किया जा सकता है, कुछ PHP संकुल $ _GET नहीं लौटाते हैं, तो देखें कि यदि 1 से अधिक $ _GET पर जाएं, तो) डिफ़ॉल्ट, यह $ _POST होगा।

Answer 14

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

Comments

कृपया लोगों को यह बताने की कोशिश न करें कि GST के बारे में POST के बारे में कुछ अधिक सुरक्षित है।

मैंने नहीं। बिंदु यह था कि उनके उपयोगों को कुछ सोचा जाना चाहिए और न कि आंतरिक रूप से इस्तेमाल किया जाना चाहिए, क्योंकि "सिर्फ टाइप करना बहुत आसान है"।

— एलेक्स ब्रासेटविक

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

Answer 15

यह बदसूरत है और मैंने इसे कोड के लाइव को आगे बढ़ाने पर अंतिम समाधान के रूप में अनुशंसित नहीं किया है, लेकिन बाकी कार्यों का निर्माण करते समय, कभी-कभी एक 'कैच-ऑल' पैरामीटर धरनेवाला होना आसान होता है:

public static function parseParams() {
    $params = array();
    switch($_SERVER['REQUEST_METHOD']) {
        case "PUT":
        case "DELETE":
            parse_str(file_get_contents('php://input'), $params);
            $GLOBALS["_{$_SERVER['REQUEST_METHOD']}"] = $params;
            break;
        case "GET":
            $params = $_GET;
            break;
        case "POST":
            $params = $_POST;
            break;
        default:
            $params = $_REQUEST;
            break;
    }
    return $params;
}

कमांड लाइन के मापदंडों को संभालने के लिए या आपके आईडीई से जो भी आता है, उसे रचनात्मक रूप से भी कोई इसमें जोड़ सकता है। एक बार जब आप यह निश्चय कर लेते हैं कि एक दिया हुआ फंक्शन क्या कर रहा है, तो आप उस दिए गए कॉल के लिए एक उपयुक्त चुन सकते हैं ताकि यह सुनिश्चित किया जा सके कि आपको तैनाती संस्करण के लिए क्या चाहिए। यह मानता है कि 'REQUEST_METHOD' सेट है।