PHP में "हेडर पहले ही भेजे गए" त्रुटि को कैसे ठीक करें




header (8)

हेडर भेजने से पहले कोई आउटपुट नहीं!

किसी भी आउटपुट से पहले HTTP हेडर भेजने / संशोधित करने वाले फ़ंक्शंस को लागू किया जाना चाहिए। सारांश ⇊ अन्यथा कॉल विफल रहता है:

चेतावनी: हेडर जानकारी संशोधित नहीं कर सकता - हेडर पहले ही भेजे गए हैं ( स्क्रिप्ट पर आउटपुट शुरू हुआ : लाइन )

HTTP शीर्षलेख को संशोधित करने वाले कुछ फ़ंक्शन हैं:

आउटपुट हो सकता है:

  • जानबूझकर:

    • print , echo और आउटपुट उत्पादन अन्य कार्यों
    • कच्चे <html> सेक्शन पहले <?php कोड।

ऐसा क्यों होता है?

यह समझने के लिए कि आउटपुट से पहले हेडर को क्यों भेजा जाना चाहिए, एक सामान्य HTTP प्रतिक्रिया को देखना आवश्यक है। PHP स्क्रिप्ट मुख्य रूप से HTML सामग्री उत्पन्न करते हैं, लेकिन वेबसर्वर पर HTTP / CGI शीर्षलेख का एक सेट भी पास करते हैं:

HTTP/1.1 200 OK
Powered-By: PHP/5.3.7
Vary: Accept-Encoding
Content-Type: text/html; charset=utf-8

<html><head><title>PHP page output page</title></head>
<body><h1>Content</h1> <p>Some more output follows...</p>
and <a href="/"> <img src=internal-icon-delayed> </a>

पेज / आउटपुट हमेशा हेडर का पालन करता है। PHP को हेडर को पहले वेबसर्वर में पास करना होगा। यह केवल एक बार ऐसा कर सकता है। डबल लाइनब्रेक के बाद यह उन्हें कभी भी संशोधित नहीं कर सकता है।

जब PHP को पहला आउटपुट प्राप्त होता है ( print , echo , <html> ) यह सभी एकत्रित शीर्षलेखों को फ्लश करेगा। इसके बाद यह सभी आउटपुट भेज सकता है जो वह चाहता है। लेकिन फिर HTTP हेडर भेजना असंभव है।

आप कैसे पता लगा सकते हैं कि समयपूर्व आउटपुट कहां हुआ?

header() चेतावनी में समस्या का पता लगाने के लिए सभी प्रासंगिक जानकारी शामिल हैं:

चेतावनी: हेडर जानकारी को संशोधित नहीं कर सकता है - लाइन 100 पर /www/usr2345/htdocs/index.php में पहले से भेजे गए हेडर (आउटपुट / www / usr2345 / htdocs / auth.php: 52 ) पर प्रारंभ किए गए हैं

यहां "लाइन 100" स्क्रिप्ट को संदर्भित करता है जहां header() आमंत्रण विफल हुआ।

कोष्ठक के भीतर " आउटपुट शुरू हुआ " नोट अधिक महत्वपूर्ण है। यह पिछले आउटपुट के स्रोत को दर्शाता है। इस उदाहरण में यह auth.php और लाइन 52 । यही वह जगह है जहां आपको समयपूर्व आउटपुट देखना था।

विशिष्ट कारण:

  1. प्रिंट, गूंज

    print और echo कथन से जानबूझकर आउटपुट HTTP शीर्षलेख भेजने का अवसर समाप्त कर देगा। इससे बचने के लिए आवेदन प्रवाह को पुनर्गठित किया जाना चाहिए। functions और templating योजनाओं का प्रयोग करें। संदेशों को लिखे जाने से पहले header() कॉल सुनिश्चित करें।

    आउटपुट उत्पन्न करने वाले कार्यों में शामिल हैं

    • print , echo , printf , vprintf
    • trigger_error , ob_flush , ob_end_flush , var_dump , print_r
    • readfile , passthru , flush , imagepng , imagejpeg


    दूसरों के बीच और उपयोगकर्ता परिभाषित कार्यों के बीच।

  2. कच्चे एचटीएमएल क्षेत्रों

    एक .php फ़ाइल में अनपढ़ HTML अनुभाग भी प्रत्यक्ष आउटपुट हैं। स्क्रिप्ट स्थितियां जो header() कॉल को ट्रिगर करती हैं उन्हें किसी भी कच्चे <html> ब्लॉक से पहले नोट किया जाना चाहिए।

    <!DOCTYPE html>
    <?php
        // Too late for headers already.
    

    आउटपुट तर्क से प्रसंस्करण को अलग करने के लिए एक टेम्पलेटिंग योजना का प्रयोग करें।

    • स्क्रिप्ट के ऊपर फॉर्म प्रसंस्करण कोड रखें।
    • संदेशों को स्थगित करने के लिए अस्थायी स्ट्रिंग चर का उपयोग करें।
    • वास्तविक आउटपुट तर्क और इंटरमीस्ड एचटीएमएल आउटपुट का पालन करना चाहिए।

  3. "Script.php लाइन 1 " चेतावनियों के लिए <?php से पहले व्हाइटस्पेस

    अगर चेतावनी लाइन 1 में आउटपुट को संदर्भित करती है, तो यह ओपनिंग <?php टोकन से पहले अधिकतर व्हाइटस्पेस , टेक्स्ट या एचटीएमएल का नेतृत्व कर रही है।

     <?php
    # There's a SINGLE space/newline before <? - Which already seals it.
    

    इसी तरह यह संलग्न स्क्रिप्ट या स्क्रिप्ट अनुभागों के लिए हो सकता है:

    ?>
    
    <?php
    

    PHP वास्तव में करीबी टैग के बाद एक एकल लाइनबैक खाता है। लेकिन यह इस तरह के अंतराल में स्थानांतरित कई नई लाइनों या टैब या रिक्त स्थान की क्षतिपूर्ति नहीं करेगा।

  4. यूटीएफ -8 बीओएम

    लाइनरेक और रिक्त स्थान अकेले एक समस्या हो सकती है। लेकिन वहां "अदृश्य" चरित्र अनुक्रम भी हैं जो इसका कारण बन सकते हैं। सबसे प्रसिद्ध यूटीएफ -8 बीओएम (बाइट-ऑर्डर-मार्क) जो अधिकांश टेक्स्ट संपादकों द्वारा प्रदर्शित नहीं होता है। यह बाइट अनुक्रम EF BB BF , जो यूटीएफ -8 एन्कोडेड दस्तावेज़ों के लिए वैकल्पिक और अनावश्यक है। हालांकि PHP को कच्चे आउटपुट के रूप में इसका इलाज करना है। यह आउटपुट में अक्षर  रूप में दिखाई दे सकता है (यदि क्लाइंट दस्तावेज़ को लैटिन -1 के रूप में व्याख्या करता है) या इसी तरह के" कचरा "।

    विशेष रूप से ग्राफिकल संपादकों और जावा आधारित आईडीई इसकी उपस्थिति के लिए अनजान हैं। वे इसे कल्पना नहीं करते हैं (यूनिकोड मानक द्वारा बाध्य)। हालांकि अधिकांश प्रोग्रामर और कंसोल संपादक करते हैं:

    समस्या को जल्दी से पहचानना आसान है। अन्य संपादक फ़ाइल / सेटिंग्स मेनू में अपनी उपस्थिति की पहचान कर सकते हैं (विंडोज़ पर नोटपैड ++ समस्या की पहचान और उपाय कर सकते हैं), बीओएम उपस्थिति का निरीक्षण करने का एक और विकल्प हेक्सएडिटर का सहारा ले रहा है। * निक्स सिस्टम hexdump आमतौर पर उपलब्ध होता है, यदि कोई ग्राफिकल संस्करण नहीं है जो इन और अन्य मुद्दों की ऑडिटिंग को सरल hexdump है:

    फाइलों को "यूटीएफ -8 (कोई बीओएम)" या इसी तरह के नामकरण के रूप में सहेजने के लिए टेक्स्ट एडिटर को सेट करना एक आसान फिक्स है। अक्सर नवागंतुक अन्यथा नई फाइलें बनाने का सहारा लेते हैं और पिछले कोड को कॉपी और पेस्ट करते हैं।

    सुधार उपयोगिताओं

    पाठ फ़ाइलों की जांच और पुनर्लेखन करने के लिए स्वचालित उपकरण भी हैं ( sed/awk या recode )। PHP के लिए विशेष रूप से phptags टैग tidier है । यह लंबे और छोटे रूपों में करीबी और खुले टैग को फिर से लिखता है, लेकिन यह आसानी से अग्रणी और पिछला सफेद स्थान, यूनिकोड और यूटीएफ-एक्स बीओएम मुद्दों को भी ठीक करता है:

    phptags  --whitespace  *.php
    

    यह पूरी तरह से शामिल या परियोजना निर्देशिका पर उपयोग करने के लिए sane है।

  5. Whitespace के बाद ?>

    अगर त्रुटि स्रोत को बंद करने के पीछे बताया गया है ?> तो यह वह जगह है जहां कुछ सफेद जगह या कच्चे पाठ को लिखा गया है। PHP अंत मार्कर इस बिंदु पर स्क्रिप्ट निष्पादन को समाप्त नहीं करता है। इसके बाद कोई भी टेक्स्ट / स्पेस वर्ण पृष्ठ सामग्री के रूप में लिखा जाएगा।

    यह आमतौर पर सलाह दी जाती है, विशेष रूप से नवागंतुकों के लिए, पीछे की ओर ?> PHP बंद टैग को छोड़ा जाना चाहिए। यह इन मामलों के एक छोटे से हिस्से को छोड़ देता है। (काफी आम तौर पर include()d स्क्रिप्ट अपराधी हैं।)

  6. "स्रोत 0 पर अज्ञात" के रूप में वर्णित त्रुटि स्रोत

    यदि कोई त्रुटि स्रोत concretized है तो यह आमतौर पर एक PHP विस्तार या php.ini सेटिंग है।

    • यह कभी-कभी gzip स्ट्रीम एन्कोडिंग सेटिंग या ob_gzhandler
    • लेकिन यह किसी भी दोगुनी लोडेड extension= मॉड्यूल भी एक अंतर्निहित PHP स्टार्टअप / चेतावनी संदेश उत्पन्न कर सकता है।

  7. पिछले त्रुटि संदेश

    यदि कोई अन्य PHP कथन या अभिव्यक्ति एक चेतावनी संदेश या नोटिस मुद्रित होने का कारण बनती है, तो यह समयपूर्व आउटपुट के रूप में भी गिना जाता है।

    इस मामले में आपको त्रुटि को छोड़ना होगा, कथन निष्पादन में देरी होगी, या उदाहरण को जारी करें isset() या @() साथ संदेश isset() - या तो बाद में डीबगिंग को बाधित नहीं करता है।

कोई त्रुटि संदेश नहीं

यदि आपके पास php.ini प्रति php.ini error_reporting या display_errors अक्षम है, तो कोई चेतावनी दिखाई नहीं देगी। लेकिन त्रुटियों को अनदेखा करने से समस्या दूर नहीं हो जाएगी। हेडर अभी भी समय से पहले उत्पादन के बाद नहीं भेजा जा सकता है।

तो जब header("Location: ...") चुपचाप रीडायरेक्ट विफल रहता है तो चेतावनियों की जांच के लिए बहुत सलाह दी जाती है। इनवेशन स्क्रिप्ट के ऊपर उन्हें दो सरल आदेशों के साथ पुन: सक्षम करें:

error_reporting(E_ALL);
ini_set("display_errors", 1);

या set_error_handler("var_dump"); यदि सभी अन्य विफल होते हैं।

रीडायरेक्ट हेडर की बात करते हुए, आपको अंतिम कोड पथों के लिए अक्सर इस तरह के मुहावरे का उपयोग करना चाहिए:

exit(header("Location: /finished.html"));

पसंदीदा रूप से एक उपयोगिता फ़ंक्शन, जो header() विफलताओं के मामले में उपयोगकर्ता संदेश मुद्रित करता है।

आउटपुट बफरिंग वर्कअराउंड के रूप में

PHPs आउटपुट बफरिंग इस समस्या को कम करने के लिए एक कामकाज है। यह अक्सर भरोसेमंद काम करता है, लेकिन उचित अनुप्रयोग संरचना के लिए विकल्प और नियंत्रण तर्क से आउटपुट को अलग नहीं करना चाहिए। इसका वास्तविक उद्देश्य वेबसर्वर को खंडित स्थानान्तरण को कम करना है।

  1. output_buffering= सेटिंग फिर भी मदद कर सकते हैं। इसे php.ini या .htaccess या यहां तक ​​कि .user.ini में आधुनिक .user.ini / .user.ini पर कॉन्फ़िगर करें।
    इसे सक्षम करने से PHP को वेबसर्वर को तुरंत पास करने के बजाय आउटपुट बफर करने की अनुमति मिल जाएगी। इस प्रकार PHP HTTP हेडर को समेकित कर सकता है।

  2. यह भी ob_start(); को कॉल के साथ लगाया जा सकता है ob_start(); आमंत्रण लिपि के ऊपर। हालांकि कई कारणों से कम विश्वसनीय है:

    • भले ही <?php ob_start(); ?> <?php ob_start(); ?> पहली स्क्रिप्ट शुरू करता है, व्हाइटस्पेस या बीओएम पहले से शफल हो सकता है, इसे अप्रभावी प्रदान करता है

    • यह एचटीएमएल आउटपुट के लिए व्हाइटस्पेस छुपा सकता है। लेकिन जैसे ही एप्लिकेशन तर्क बाइनरी सामग्री (उदाहरण के लिए जेनरेट की गई छवि) भेजने का प्रयास करता है, बफर किए गए बाहरी आउटपुट एक समस्या बन जाते हैं। ( ob_clean() को ob_clean() वर्कअराउंड के रूप में आवश्यक है।)

    • बफर आकार में सीमित है, और डिफ़ॉल्ट रूप से छोड़े जाने पर आसानी से ओवररन कर सकता है। और यह एक दुर्लभ अवसर नहीं है, जब ऐसा होता है तो ट्रैक करना मुश्किल होता है।

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

मैन्युअल में बुनियादी उपयोग उदाहरण और अधिक पेशेवरों और विपक्ष के लिए भी देखें:

लेकिन यह दूसरे सर्वर पर काम किया !?

यदि आपको पहले हेडर चेतावनी नहीं मिली है, तो output_buffering= बदल गई है। यह वर्तमान / नए सर्वर पर असुरक्षित होने की संभावना है।

headers_sent() साथ जांच

जांच के लिए आप हमेशा headers_sent() का उपयोग कर सकते हैं यदि यह अभी भी संभव है ... हेडर भेजें। सशर्त रूप से एक जानकारी मुद्रित करने या अन्य फ़ॉलबैक तर्क लागू करने के लिए उपयोगी है।

if (headers_sent()) {
    die("Redirect failed. Please click on this link: <a href=...>");
}
else{
    exit(header("Location: /user.php"));
}

उपयोगी फॉलबैक वर्कअराउंड हैं:

  • एचटीएमएल <meta> टैग

    यदि आपका एप्लिकेशन संरचनात्मक रूप से ठीक करने के लिए कठिन है, तो रीडायरेक्ट को अनुमति देने के लिए एक आसान (लेकिन कुछ हद तक गैर-व्यावसायिक) तरीका HTML <meta> टैग इंजेक्शन दे रहा है। एक रीडायरेक्ट के साथ हासिल किया जा सकता है:

     <meta http-equiv="Location" content="http://example.com/">
    

    या थोड़ी देर के साथ:

     <meta http-equiv="Refresh" content="2; url=../target.html">
    

    <head> सेक्शन का उपयोग करते समय यह गैर-मान्य HTML की ओर जाता है। अधिकांश ब्राउज़र अभी भी इसे स्वीकार करते हैं।

  • जावास्क्रिप्ट पुनर्निर्देशित

    वैकल्पिक रूप से एक जावास्क्रिप्ट रीडायरेक्ट पेज रीडायरेक्ट के लिए इस्तेमाल किया जा सकता है:

     <script> location.replace("target.html"); </script>
    

    हालांकि यह अक्सर <meta> वर्कअराउंड से अधिक HTML अनुपालन करता है, यह जावास्क्रिप्ट-सक्षम ग्राहकों पर निर्भरता उत्पन्न करता है।

वास्तविक HTTP शीर्षलेख () कॉल असफल होने पर दोनों दृष्टिकोण स्वीकार्य फॉलबैक करते हैं। आदर्श रूप में आप इसे हमेशा उपयोगकर्ता के अनुकूल संदेश और अंतिम उपाय के रूप में क्लिक करने योग्य लिंक के साथ जोड़ते हैं। (उदाहरण के लिए http_redirect() एक्सटेंशन क्या करता है।)

क्यों setcookie() और session_start() भी प्रभावित होते हैं

दोनों setcookie() और session_start() को Set-Cookie: भेजने की आवश्यकता है Set-Cookie: HTTP शीर्षलेख। इसलिए वही स्थितियां लागू होती हैं, और समान त्रुटि संदेश समयपूर्व आउटपुट स्थितियों के लिए उत्पन्न किए जाएंगे।

(बेशक वे ब्राउज़र में अक्षम कुकीज़ या यहां तक ​​कि प्रॉक्सी मुद्दों से भी प्रभावित होते हैं। सत्र कार्यक्षमता स्पष्ट रूप से फ्री डिस्क स्पेस और अन्य php.ini सेटिंग्स आदि पर भी निर्भर करती है)

आगे के लिंक

मेरी स्क्रिप्ट चलाते समय, मुझे इस तरह की कई त्रुटियां मिल रही हैं:

चेतावनी: हेडर जानकारी संशोधित नहीं कर सकता है - लाइन 23 पर /some/file.php में पहले से भेजे गए हेडर ( /ome /file.php:12 पर आउटपुट )

त्रुटि संदेशों में उल्लिखित रेखाओं में header() और setcookie() कॉल शामिल हैं।

इसका क्या कारण रह सकता है? और इसे कैसे ठीक करें?


HTTP हेडर ( setcookie() या header() ) भेजने से पहले कुछ भी भेजा जाने पर यह त्रुटि संदेश ट्रिगर हो जाता है। HTTP हेडर से पहले कुछ आउटपुट करने के सामान्य कारण हैं:

  • दुर्घटनाग्रस्त सफेद जगह, अक्सर फाइलों की शुरुआत या अंत में, इस तरह:

     <?php
    // Note the space before "<?php"
    ?>
    

इससे बचने के लिए, बस बंद करना छोड़ दें ?> - वैसे भी इसकी आवश्यकता नहीं है।

  • एक PHP फ़ाइल की शुरुआत में बाइट ऑर्डर अंक । यह पता लगाने के लिए कि क्या यह मामला है, एक हेक्स संपादक के साथ अपनी PHP फाइलों की जांच करें। उन्हें बाइट्स 3F 3C शुरू करना चाहिए। आप फाइलों की शुरुआत से बीओएम EF BB BF को सुरक्षित रूप से हटा सकते हैं।
  • स्पष्ट आउटपुट, जैसे echo , printf , readfile , passthru , कोड से पहले कॉल करने के लिए कॉल <? आदि।
  • Php द्वारा outputted एक चेतावनी, अगर display_errors php.ini प्रॉपर्टी सेट है। प्रोग्रामर गलती पर दुर्घटनाग्रस्त होने के बजाय, php चुपचाप त्रुटि को ठीक करता है और चेतावनी देता है। जबकि आप display_errors या error_reporting कॉन्फ़िगरेशन को संशोधित कर सकते हैं, आपको समस्या को ठीक करना चाहिए।
    सामान्य कारण किसी सरणी के अनिर्धारित तत्वों (जैसे $_POST['input'] isset() लिए empty या जारी करने के बिना इनपुट का सेट किए गए हैं, या स्ट्रिंग अक्षर के बजाय एक अपरिभाषित स्थिरांक का उपयोग कर रहे हैं (जैसे $_POST[input] , गायब उद्धरण नोट करें)।

आउटपुट बफरिंग को चालू करने से समस्या दूर होनी चाहिए; ob_start(); कॉल के बाद सभी आउटपुट स्मृति में buffered है जब तक आप बफर जारी नहीं करते हैं, उदाहरण के लिए ob_end_flush

हालांकि, आउटपुट बफरिंग मुद्दों से बचाता है, आपको वास्तव में यह निर्धारित करना चाहिए कि आपका हेडर HTTP हेडर से पहले HTTP निकाय क्यों आउटपुट करता है। यह एक फोन कॉल लेने और कॉलर को बताने से पहले अपने दिन और मौसम पर चर्चा करने जैसा होगा कि उसे गलत नंबर मिला है।


उपयोग

ob_start ();

आपकी लिपि के शीर्ष पर, और

ob_end_flush ();

आपकी लिपि के नीचे। इस पृष्ठ को बफर करने के बाद आउटपुट बफरिंग हो जाएगी और आपके हेडर बनाए जाएंगे।

सामान्य समस्यायें:

====================

( source से कॉपी किया गया: source )

1) header(.......); से पहले कोई आउटपुट (यानी echo.. या एचटीएमएल कोड) नहीं होना चाहिए header(.......); आदेश।

2) <?php और बाद में ?> टैग से पहले किसी भी सफेद-स्थान (या नई लाइन ) को हटा दें।

3) गोल्डन नियम! - जांचें कि क्या PHP फ़ाइल (और, यदि आप अन्य फाइलें भी include करते हैं) में बीओएम एन्कोडिंग के बिना यूटीएफ 8 है (और केवल यूटीएफ -8 नहीं)। यह कई मामलों में समस्या है (क्योंकि यूटीएफ 8 एन्कोडेड फ़ाइल में PHP फ़ाइल की शुरुआत में कुछ विशेष चरित्र है, जो आपका टेक्स्ट-संपादक नहीं दिखाता है) !!!!!!!!!!!

4) header(...); बाद header(...); आपको exit; उपयोग करना चाहिए exit;

5) हमेशा 301 या 302 संदर्भ का उपयोग करें:

header("location: http://example.com",  true,  301 );  exit;

6) त्रुटि रिपोर्टिंग चालू करें। और त्रुटि बताओ।

7) यदि उपरोक्त में से कोई भी मदद नहीं करता है, तो JAVSCRIPT पुनर्निर्देशन (हालांकि, दृढ़ता से अनुशंसित विधि) का उपयोग करें, कस्टम मामलों में अंतिम मौका हो सकता है ...:

echo "<script type='text/javascript'>window.top.location='http://website.com/';</script>"; exit;

एक और बुरी आदत इस समस्या का आह्वान कर सकती है जिसे अभी तक नहीं बताया गया है।

यह कोड स्निपेट देखें:

<?php
include('a_important_file.php'); //really really really bad practise
header("Location:A location");
?>

चीजें ठीक हैं, है ना?

क्या होगा यदि "a_important_file.php" यह है:

<?php
//some php code 
//another line of php code
//no line above is generating any output
?>

 ----------This is the end of the an_important_file-------------------

यह काम नहीं करेगा? क्यों? क्योंकि पहले से ही एक नई लाइन उत्पन्न हुई है।

अब, हालांकि यह एक सामान्य परिदृश्य नहीं है, यदि आप एक एमवीसी फ्रेमवर्क का उपयोग कर रहे हैं जो आपके नियंत्रक को चीजों को सौंपने से पहले बहुत सारी फाइल लोड करता है? यह एक असामान्य परिदृश्य नहीं है। इसके लिए तैयार रहें।

पीएसआर -2 2.2 से:

  • सभी PHP फ़ाइलों को Unix LF (linefeed) line ending उपयोग करना होगा।
  • सभी PHP फ़ाइलों को single blank line साथ समाप्त होना चाहिए।
  • समापन?> टैग only php फाइलों वाली फाइलों से omitted जाना चाहिए

मेरा विश्वास करो, इन मानकों के बाद आपको अपने जीवन से बहुत सारे घंटे बचा सकते हैं :)


कभी-कभी जब देव प्रक्रिया में WIN कार्य स्टेशन और LINUX सिस्टम (होस्टिंग) दोनों होते हैं और कोड में आपको संबंधित रेखा से पहले कोई आउटपुट नहीं दिखाई देता है, तो यह फ़ाइल का स्वरूपण हो सकता है और यूनिक्स एलएफ (लाइनफीड) लाइन अंत की कमी हो सकती है ।

हम इसे तुरंत ठीक करने के लिए आमतौर पर क्या करते हैं, फ़ाइल का नाम बदलते हैं और LINUX सिस्टम पर नामित एक के बजाय एक नई फ़ाइल बनाते हैं, और उसके बाद सामग्री को प्रतिलिपि बनाएँ। कई बार इस मुद्दे को हल करते हैं क्योंकि WIN में बनाए गए कुछ फ़ाइलों को एक बार होस्टिंग में स्थानांतरित करने के कारण इस समस्या का कारण बनता है।

यह फिक्स एफ़टीपी द्वारा प्रबंधित साइटों के लिए एक आसान फिक्स है और कभी-कभी हमारे नए टीम के सदस्यों को कुछ समय बचा सकता है।


तुम करो

printf ("Hi %s,</br />", $name);

कुकीज़ सेट करने से पहले, जिसकी अनुमति नहीं है। आप हेडर से पहले कोई आउटपुट नहीं भेज सकते हैं, यहां तक ​​कि रिक्त रेखा भी नहीं।


मुझे यह त्रुटि कई बार पहले मिली। और मुझे यकीन है कि सभी PHP प्रोग्रामर को कम से कम एक बार यह त्रुटि मिली है। इस त्रुटि को हल करने के लिए आप अपने समस्या स्तर के अनुसार उपयोग समाधान हल कर सकते हैं:

संभावित समाधान 1:

हो सकता है कि आपने पहले या बाद में (फ़ाइल के अंत में?>) यानी रिक्त स्थान छोड़े हों

THERE SHOULD BE NO BLANK SPACES HERE
<?php  

   echo "your code here";

?>
DO CHECK FOR BLANK SPACES HERE AS WELL; THIS LINE (blank line) SHOULD NOT EXIST.

अधिकांश समय यह आपकी समस्या का समाधान करना चाहिए। आपको require फाइल से जुड़े सभी फाइलों की जांच करें।

नोट: कभी-कभी संपादक (आईडीई) जैसे जीएडिट (एक डिफ़ॉल्ट लिनक्स संपादक) फ़ाइल को सहेजने पर एक खाली रेखा जोड़ता है। ऐसा नहीं होना चाहिए। यदि आप लिनक्स का उपयोग कर रहे हैं। पृष्ठ के अंत में आप अंतरिक्ष / रेखाओं को हटाने के बाद VI संपादक का उपयोग कर सकते हैं।

यदि यह आपका मामला नहीं है, तो आप नीचे दिए गए आउटपुट बफरिंग के लिए ob_start उपयोग कर सकते हैं:

संभावित समाधान 2:

<?php
  ob_start();

  // code 

 ob_end_flush();
?> 

यह इस पंक्ति के कारण है:

printf ("Hi %s,</br />", $name);

हेडर भेजने से पहले आपको कुछ प्रिंट / गूंज नहीं करना चाहिए।





header