Podczas uruchamiania skryptu otrzymuję kilka błędów takich jak ten:
Ostrzeżenie: Nie można modyfikować informacji nagłówka - nagłówki zostały już wysłane przez (wyjście rozpoczęło się w /some/file.php:12) w /some/file.php w linii 23
Wiersze wymienione w komunikatach o błędach zawierają header() i setcookie() połączeń.
Co mogłoby być tego przyczyną? Jak to naprawić?
Funkcje wysyłające/modyfikujące nagłówki HTTP muszą zostać wywołane przed wykonaniem jakichkolwiek danych wyjściowych. podsumowanie ⇊ W przeciwnym razie połączenie nie powiedzie się:
Ostrzeżenie: nie można modyfikować informacji nagłówka — nagłówki zostały już wysłane (wyjście rozpoczęło się od script:line)
Niektóre funkcje modyfikujące nagłówek HTTP to:
header / header_remove< /a>session_start / session_regenerate_id< /a>setcookie / setrawcookie< /a>Dane wyjściowe mogą być:
Niezamierzone:
<?php or after ?>Zamierzone:
print, echo and other functions producing output<html> sekcje przed kodem <?php.Aby zrozumieć, dlaczego nagłówki muszą zostać wysłane przed wyjściem, należy przyjrzeć się typowej odpowiedzi HTTP. Skrypty PHP generują głównie treść HTML, ale przekazują także zestaw nagłówków HTTP/CGI do serwera WWW:
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>
Strona/wyjście zawsze podąża za nagłówkami. PHP musi najpierw przekazać nagłówki do serwera WWW. Może to zrobić tylko raz. Po podwójnym podziale linii nie można już ich zmieniać.
Kiedy PHP otrzyma pierwsze wyjście (print, echo, <html>), opróżni wszystkie zebrane nagłówki. Następnie może wysłać dowolne dane wyjściowe. Jednak wysłanie dalszych nagłówków HTTP jest wtedy niemożliwe.
Ostrzeżenie header() zawiera wszystkie istotne informacje umożliwiające zlokalizowanie przyczyny problemu:
Ostrzeżenie: nie można modyfikować informacji nagłówka — nagłówki zostały już wysłane przez (wyjście rozpoczęło się od /www/usr2345/htdocs/auth.php:52) w /www/usr2345/htdocs/index.php w linii 100
Tutaj linia 100 odnosi się do skryptu, w którym header() wywołanie nie powiodło się.
Wyjście rozpoczynające się od notatki w nawiasie jest bardziej znaczące. Oznacza źródło poprzedniego wyniku. W tym przykładzie jest to auth.php i linia 52. To tam trzeba było szukać przedwczesnych wyników.
Typowe przyczyny:
Zamierzone wyjście z instrukcji print i echo zakończy możliwość wysyłania nagłówków HTTP. Aby tego uniknąć, należy zrestrukturyzować przepływ aplikacji. Używaj funkcji i schematów szablonów. Upewnij się, że header() wywołania mają miejsce zanim wiadomości zostaną zapisane.
Funkcje generujące dane wyjściowe obejmują
print, echo, printf, vprintftrigger_error, ob_flush, ob_end_flush, var_dump, print_rreadfile, passthru, flush, imagepng, imagejpeg
i funkcje zdefiniowane przez użytkownika.
Nieprzeanalizowane sekcje HTML w pliku .php również są bezpośrednim wyjściem. Warunki skryptu, które wyzwolą wywołanie header(), muszą zostać zapisane przed jakimkolwiek nieprzetworzonym <html> blokiem.
<!DOCTYPE html>
<?php
// Too late for headers already.
Użyj schematu szablonów, aby oddzielić przetwarzanie od logiki wyjściowej.
<?php dla ostrzeżeń linia 1 script.phpJeśli ostrzeżenie odnosi się do wbudowanego wyjścia 1, wówczas przed otwierającym tokenem <?php jest to głównie biała spacja, tekst lub kod HTML.
<?php
# There's a SINGLE space/newline before <? - Which already seals it.
Podobnie może się to zdarzyć w przypadku dołączonych skryptów lub sekcji skryptów:
?>
<?php
PHP faktycznie zjada pojedynczy podział linii po zamykających tagach. Ale nie zrekompensuje to wielu znaków nowej linii, tabulatorów lub spacji przesuniętych w takie luki.
#P25# 
#P26# #P65# #P27# phptags --whitespace *.php
?>Jeśli źródło błędu jest wymienione jako znajdujące się za zamykaniem ?>, to w tym miejscu pojawiły się białe znaki lub nieprzetworzony tekst wypisane. Znacznik końca PHP nie kończy w tym momencie wykonywania skryptu. Wszelkie znaki tekstowe/spacje po nim zostaną zapisane jako treść strony.
Powszechnie zaleca się, zwłaszcza nowicjuszom, aby pomijać końcowe znaczniki zamykające ?> PHP. To pomija niewielką część tych przypadków. (Często winowajcą są include()d skrypty.)
Zwykle jest to rozszerzenie PHP lub ustawienie php.ini, jeśli nie jest określone żadne źródło błędu.
gzip stream encoding setting
or the ob_gzhandler.extension= generujący ukryty komunikat ostrzegawczy/ostrzegawczy PHP.Jeśli inna instrukcja lub wyrażenie PHP powoduje wydrukowanie komunikatu ostrzegawczego lub powiadomienia, liczy się to również jako przedwczesne wyjście.
W takim przypadku należy uniknąć błędu, opóźnić wykonanie instrukcji lub ukryć komunikat za pomocą np. isset() lub @()< /a> - gdy którykolwiek z nich nie utrudnia późniejszego debugowania.
Jeśli masz wyłączone error_reporting lub display_errors na php.ini, nie pojawi się żadne ostrzeżenie. Ale ignorowanie błędów nie sprawi, że problem zniknie. Nagłówków nadal nie można wysłać po przedwczesnym wyjściu.
Zatem gdy przekierowania header("Location: ...") po cichu zawodzą, bardzo wskazane jest sprawdzenie ostrzeżeń. Włącz je ponownie za pomocą dwóch prostych poleceń znajdujących się na skrypcie wywołania:
error_reporting(E_ALL);
ini_set("display_errors", 1);
Lub set_error_handler("var_dump");, jeśli wszystko inne zawiedzie.
Mówiąc o nagłówkach przekierowań, często powinieneś używać takiego idiomu dla końcowych ścieżek kodu:
exit(header("Location: /finished.html"));
Najlepiej nawet funkcja narzędziowa, która wypisuje komunikat użytkownika w przypadku header() awarii.
buforowanie danych wyjściowych w PHP jest obejściem tego problemu. Często działa niezawodnie, ale nie powinno zastępować odpowiedniego strukturyzacji aplikacji i oddzielania danych wyjściowych od logiki sterującej. Jego rzeczywistym celem jest minimalizacja fragmentarycznych transferów do serwera WWW.
Niemniej jednak ustawienie output_buffering= może być pomocne. Skonfiguruj go w php.ini lub przez .htaccess lub nawet .user.ini w nowoczesnych konfiguracjach FPM/FastCGI.
Włączenie tej opcji pozwoli PHP buforować dane wyjściowe zamiast przekazywać je do serwera WWW natychmiast. PHP może w ten sposób agregować nagłówki HTTP.
Można go również wywołać poprzez wywołanie ob_start(); na górze skryptu wywołania. Który jednak jest mniej niezawodny z wielu powodów:
Nawet jeśli <?php ob_start(); ?> uruchomi pierwszy skrypt, białe znaki lub BOM mogą zostać wcześniej przetasowane, co czyni go nieskutecznym.
Może ukrywać białe znaki w wynikach HTML. Jednak gdy tylko logika aplikacji spróbuje wysłać zawartość binarną (na przykład wygenerowany obraz), buforowane zewnętrzne wyjście staje się problemem. (Wymagane jest dalsze obejście problemu ob_clean().)
Bufor ma ograniczony rozmiar i może łatwo zostać przepełniony, jeśli pozostawi się go do ustawień domyślnych. I to też nie jest rzadkie zjawisko, trudne do wyśledzenia kiedy to się stanie.
Dlatego oba podejścia mogą stać się zawodne - w szczególności podczas przełączania między konfiguracjami programistycznymi i/lub serwerami produkcyjnymi. Dlatego buforowanie wyjścia jest powszechnie uważane za pomocną/ściśle obejście.
Zobacz także podstawowy przykład użycia w podręczniku i więcej plusy i minusy:
Jeśli wcześniej nie pojawiło się ostrzeżenie dotyczące nagłówków, skorzystaj z ustawienia buforowania danych wyjściowych w pliku php.ini uległo zmianie. Prawdopodobnie nie jest skonfigurowany na bieżącym/nowym serwerze.
headers_sent()Zawsze możesz użyć headers_sent(), aby sprawdzić, czy nadal możliwe jest... wysyłanie nagłówków. Co jest przydatne do warunkowego drukowania informacji lub stosowania innej logiki awaryjnej.
if (headers_sent()) {
die("Redirect failed. Please click on this link: <a href=...>");
}
else{
exit(header("Location: /user.php"));
}
Przydatne rozwiązania awaryjne to:
<meta>Jeśli struktura Twojej aplikacji jest trudna do naprawienia, prostym (ale nieco nieprofesjonalnym) sposobem zezwolenia na przekierowania jest wstrzyknięcie tagu HTML <meta>. Przekierowanie można osiągnąć za pomocą:
<meta http-equiv="Location" content="http://example.com/">
Lub z krótkim opóźnieniem:
<meta http-equiv="Refresh" content="2; url=../target.html">
Prowadzi to do nieprawidłowego kodu HTML, jeśli jest używany poza sekcją <head>. Większość przeglądarek nadal to akceptuje.
Alternatywnie można zastosować przekierowanie JavaScript w przypadku przekierowań stron:
<script> location.replace("target.html"); </script>
Chociaż jest to często bardziej zgodne z HTML niż obejście <meta>, wiąże się z koniecznością polegania na klientach obsługujących JavaScript.
Obydwa podejścia zapewniają jednak akceptowalne rozwiązania awaryjne, gdy oryginalne wywołania nagłówka HTTP nie powiodą się. Idealnie byłoby, gdybyś w ostateczności zawsze łączył to z przyjazną dla użytkownika wiadomością i klikalnym linkiem. (Co na przykład robi rozszerzenie http://php.net/http_redirect PECL.)
setcookie() i session_start()Zarówno setcookie(), jak i session_start() muszą wysłać Set-Cookie: nagłówek HTTP. Obowiązują zatem te same warunki i podobne komunikaty o błędach będą generowane w przypadku przedwczesnych sytuacji wyjściowych.
(Oczywiście mają na nie wpływ także wyłączone pliki cookie w przeglądarce lub nawet problemy z serwerem proxy. Funkcjonalność sesji zależy oczywiście również od wolnego miejsca na dysku i innych ustawień php.ini itp.)
?> z końca plików php jest zwykle dobrą praktyką, która pomaga również zminimalizować te błędy. Na końcu plików nie będą pojawiać się niechciane białe znaki, a nagłówki odpowiedzi nadal będzie można później dodać. Jest to również przydatne, jeśli używasz buforowania danych wyjściowych i nie chcesz, aby na końcu części generowanych przez dołączone pliki dodano niechciane białe znaki.
- person Nikita 웃; 08.02.2016
curl i nie ustawienie CURLOPT_RETURNTRANSFER na TRUE może również wygenerować dane wyjściowe i dlatego wywołać błąd „nagłówki już wysłane”
- person kask; 19.03.2018
<?php w jednym z moich dołączonych plików.
- person AnalogWeapon; 20.05.2018
ob_start(); rozwiązało problem. Dzięki
- person Jodyshop; 16.08.2019
$file = $line = null; headers_sent($file, $line); die("$file:$line"); powie Ci dokładnie, co wysłało nagłówki, jeśli komunikat o błędzie pominie tę informację. Nie jestem pewien dlaczego, ale czasami wydaje się, że tak jest.
- person kmuenkel; 16.06.2021
Ten komunikat o błędzie jest wyświetlany, gdy cokolwiek zostanie wysłane przed wysłaniem nagłówków HTTP (z setcookie lub header). Typowe powody wypisywania czegoś przed nagłówkami HTTP to:
Przypadkowe białe znaki, często na początku lub na końcu plików, takie jak to:
<?php
// Note the space before "<?php"
?>
Aby tego uniknąć, po prostu pomiń zamknięcie ?> - i tak nie jest to wymagane.
3F 3C. Możesz bezpiecznie usunąć BOM EF BB BF z początku plików.echo, printf, readfile, passthru, kod przed <? itp.display_errors php.ini. Zamiast zawieszać się z powodu błędu programisty, php po cichu naprawia błąd i emituje ostrzeżenie. Chociaż możesz modyfikować display_errors lub error_reporting, powinieneś raczej naprawić problem.$_POST['input'] bez użycia empty lub isset, aby sprawdzić, czy dane wejściowe są set) lub użycie niezdefiniowanej stałej zamiast literału łańcuchowego (jak w $_POST[input], zwróć uwagę na brakujące cudzysłowy).Włączenie buforowanie danych wyjściowych powinno sprawić, że problem zniknie; wszystkie dane wyjściowe po wywołaniu ob_start są buforowane w pamięci do czasu zwolnienia bufora, np. z ob_end_flush.
Jednakże, chociaż buforowanie danych wyjściowych pozwala uniknąć problemów, tak naprawdę powinieneś określić, dlaczego aplikacja wysyła treść HTTP przed nagłówkiem HTTP. To jakby odebrać telefon i omówić swój dzień i pogodę, zanim powiesz rozmówcy, że pomylił numer.
Zamiast poniższej linii
//header("Location:".ADMIN_URL."/index.php");
pisać
echo("<script>location.href = '".ADMIN_URL."/index.php?msg=$msg';</script>");
or
?><script><?php echo("location.href = '".ADMIN_URL."/index.php?msg=$msg';");?></script><?php
To na pewno rozwiąże Twój problem. Napotkałem ten sam problem, ale rozwiązałem go, pisząc lokalizację nagłówka w powyższy sposób.
Ty robisz
printf ("Hi %s,</br />", $name);
przed ustawieniem plików cookies, co jest niedozwolone. Nie możesz wysłać żadnego wyniku przed nagłówkami, nawet pustej linii.
(skopiowano z: źródło)
====================
1) przed poleceniem header(.......); nie powinno być żadnych danych wyjściowych (tj. echo.. lub kodów HTML).
2) usuń wszelkie białe znaki (lub nową linię) przed tagami <?php i po ?>.
3) ZŁOTA ZASADA! - sprawdź, czy ten plik php (a także, jeśli masz include inne pliki) mają kodowanie UTF8 bez BOM (a nie po prostu UTF-8). W wielu przypadkach jest to problem (ponieważ plik zakodowany w formacie UTF8 ma na początku pliku php jakiś specjalny znak, czego twój edytor tekstu nie pokazuje)!!!!!!!!!!!
4) Po header(...); musisz użyć exit;
5) zawsze używaj odniesienia 301 lub 302:
header("location: http://example.com", true, 301 ); exit;
6) Włącz raportowanie błędów i znajdź błąd. Twój błąd może być spowodowany niedziałającą funkcją. Po włączeniu raportowania błędów należy zawsze najpierw naprawić błąd znajdujący się na pierwszym miejscu. Może to być na przykład „Ostrzeżenie: date_default_timezone_get(): Nie jest bezpiecznie polegać na ustawieniach strefy czasowej systemu”. - dalej w dół może pojawić się błąd „nagłówki nie zostały wysłane”. Po naprawieniu najwyższego (pierwszego) błędu załaduj ponownie stronę. Jeśli nadal występują błędy, ponownie napraw najwyższy błąd.
7) Jeśli żadne z powyższych nie pomoże, użyj przekierowania JAVSCRIPT (jednak zdecydowanie niezalecana metoda), może to być ostatnia szansa w niestandardowych przypadkach...:
echo "<script type='text/javascript'>window.top.location='http://website.com/';</script>"; exit;
301 lub 302 jest ważne?
- person Jānis Elmeris; 15.04.2019
Dzieje się tak z powodu tej linii:
printf ("Hi %s,</br />", $name);
Nie należy drukować/echa niczego przed wysłaniem nagłówków.
Prosta wskazówka: zwykła spacja (lub niewidoczny znak specjalny) w skrypcie, tuż przed pierwszym znacznikiem <?php, może to spowodować! Zwłaszcza gdy pracujesz w zespole i ktoś używa „słabego” IDE lub grzebał w plikach dziwnymi edytorami tekstu.
Widziałem takie rzeczy ;)
Inna zła praktyka może powodować ten problem, który nie został jeszcze stwierdzony.
Zobacz ten fragment kodu:
<?php
include('a_important_file.php'); //really really really bad practise
header("Location:A location");
?>
Wszystko w porządku, prawda?
A co jeśli „a_important_file.php” to:
<?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-------------------
To nie zadziała? Dlaczego? Ponieważ jest już generowana nowa linia.
Chociaż nie jest to częsty scenariusz, co się stanie, jeśli używasz frameworka MVC, który ładuje dużo plików przed przekazaniem rzeczy do kontrolera? To nie jest rzadki scenariusz. Bądź na to przygotowany.
Unix LF (linefeed) line ending.single blank line.omitted z plików zawierających only phpUwierz mi, przestrzeganie tych standardów może zaoszczędzić mnóstwo godzin życia :)
?> w żadnym pliku
- person Daniel W.; 04.04.2014
CR LF (typowy koniec linii w systemie Windows). Rozwiązuję ten problem, pobierając oryginalny plik z repozytorium Wordpress, który ma LF (koniec linii w Linuksie) zamiast CR LF, a także przeniosłem moją funkcję do plikufunctions.php motywu. Na podstawie: bit.ly/1Gh6mzN
- person Junior Mayhé; 11.06.2015
?> <?php, usuwając i dodając pojedynczą pustą linię, dodając i pomijając znacznik zamykający ?>. W Windows+ Wamp wszystkie te kombinacje działają dobrze. Dziwne...
- person Junior Mayhé; 11.06.2015
header(), a główny skrypt (o bardzo podobnej nazwie) wygenerował dane wyjściowe przed dołączeniem.
- person rubo77; 26.03.2021
Czasami, gdy proces deweloperski obejmuje zarówno stacje robocze WIN, jak i systemy LINUX (hosting), a w kodzie nie widać żadnych danych wyjściowych przed odpowiednią linią, może to być spowodowane formatowaniem pliku i brakiem Unix LF (linefeed ) zakończenie linii.
Aby szybko to naprawić, zwykle zmieniamy nazwę pliku i w systemie LINUX tworzymy nowy plik zamiast pliku o zmienionej nazwie, a następnie kopiujemy do niego zawartość. Wiele razy rozwiązuje to problem, ponieważ niektóre pliki utworzone w WIN po przeniesieniu na hosting powodują ten problem.
Ta poprawka jest łatwa w przypadku witryn zarządzanych przez FTP i czasami może zaoszczędzić trochę czasu naszym nowym członkom zespołu.
Zwykle ten błąd pojawia się, gdy wysyłamy nagłówek po wywołaniu echa lub wydrukowaniu. Jeśli ten błąd pojawi się na konkretnej stronie, przed wywołaniem start_session() upewnij się, że strona nie powtarza niczego.
Przykład nieprzewidywalnego błędu:
<?php //a white-space before <?php also send for output and arise error
session_start();
session_regenerate_id();
//your page content
Jeszcze jeden przykład:
<?php
includes 'functions.php';
?> <!-- This new line will also arise error -->
<?php
session_start();
session_regenerate_id();
//your page content
Wniosek: Nie wyprowadzaj żadnych znaków przed wywołaniem funkcji session_start() lub header(), nawet jeśli jest to spacja lub nowa linia
ob_start() po prostu ukrywa problem; nie używaj go do rozwiązania tego konkretnego problemu.
- person Ja͢ck; 15.05.2013
ob_start(), to co powinienem zrobić, aby rozwiązać ten problem: Headers already sent
- person Shafizadeh; 14.07.2015
ob_start() nie ukrywa problemu, on rozwiązuje problem.
- person Tomas; 22.10.2015
<?
- person Manish Shrivastava; 06.05.2017
ob_start();. ponieważ po dodaniu ob_start(); nadal pojawia się błąd. Musisz dodać do strony, która uruchomiła bieżącą stronę. Np.: strona 1 (kliknięcie przycisku) -› strona 2. (przekierowanie nagłówka) -› strona 0 (strona główna). Musisz dodać go do strony 1. Wiele osób było zdezorientowanych i dodało na stronie 2.
- person Dexter; 07.08.2018
ob_startiob_end_clean()). Następnie możesz ustawić plik cookie lub sesję równąob_get_contents(), a następnie użyćob_end_clean()do wyczyszczenia bufora. - person Jack schedule 04.04.2014safeRedirectw mojej bibliotece PHP: github.com/heinkasner/PHP -Biblioteka/blob/master/extra.php - person heinkasner schedule 24.07.2014UTF-8, aleUTF-8 (Without BOM)~~~~~~~~~~~ - person T.Todua schedule 19.09.2014