So. Ich habs: File: fake404.cgi ~~~PHP,bad #!/usr/bin/php Status: 404 Content-Type:text/html; charset=utf-8 <h1>Hier wird ein 404er gefälscht.</h1> <hr> <?php echo date('Y-m-d H:i:s');?> ~~~ (Das ist nicht im eigentlichen Sinne falsch, der Code funktioniert - **es soll nur keiner nachmachen**, der nicht meinen Test wiederholen will.) Die Programmiersprache ist egal, das würde mit Perl, Bash, Javascript (node.js), Python ... auch so klappen (ich hätte dann aber mit print bzw. echo einige Mühe...). PHP gibt die Zeilen außerhalb `<?php ... ?>` 1:1 zurück. Das mache ich mir oben zu nutze. Ausgaben im Terminal nach `chmod 755 fake404.cgi; ./fake404.cgi` ~~~ Status: 404 Content-Type:text/html; charset=utf-8 <h1>Hier wird ein 404er gefälscht.</h1> <hr> 2022-03-24 13:40:08 ~~~ ... abholen via Webserver: ~~~ < HTTP/1.1 404 Not Found < Date: Thu, 24 Mar 2022 12:45:52 GMT < Server: Apache/2.4.52 < Permissions-Policy: interest-cohort=() < Transfer-Encoding: chunked < Content-Type: text/html; charset=utf-8 < <h1>Hier wird ein 404er gefälscht.</h1> <hr> 2022-03-24 13:42:33 ~~~ ( `curl -v` markiert die Response-Headerzeilen mit vorangestelltem '< '). Das entspricht dem, was ich einst mit Perl lernte. Die erste leere Zeile im Ausgabestrom eines CGI-Skriptes trennt den HTTP-Header vom Payload (oft aber nicht immer: der Webseite). Es ist hier das **CGI-Modul des Webservers**, welches den Datenstrom entgegen nimmt und die HTTP-Header ersetzt bzw. ergänzt. **Also nicht PHP.** Übrigens ist eine Zeile mit dem Content-Type verpflichtend, sonst: „Error 500“. Dieses Problem wurde in Zeiten, als Perl/Cgi noch in Mode war, in diesem Forum ganz oft auf den Tisch gebracht... (Und schaut mal hier, in die alte Doku, die Google sehr gerne findet: http://www-hera-b.desy.de/subgroup/computing/IT/www/selfhtml/cgiperl/sprache/cginotwendig.htm) Insofern braucht sich niemand wundern, warum etwas wie *"Status: 404"* im PHP-Handbuch nicht vorkommt: PHP hat damit nichts zu tun. Im Apache Handbuch, den Seiten zu *-cgi, sollte aber dazu was stehen.

So. Ich habs: File: fake404.cgi ~~~PHP,bad #!/usr/bin/php Status: 404 Content-Type:text/html; charset=utf-8 <h1>Hier wird ein 404er gefälscht.</h1> <hr> <?php echo date('Y-m-d H:i:s');?> ~~~ (Das ist nicht im eigentlichen Sinne falsch, der Code funktioniert - **es soll nur keiner nachmachen**, der nicht meinen Test wiederholen will.) Die Programmiersprache ist egal, das würde mit Perl, Bash, Javascript (node.js), Python ... auch so klappen (ich hätte dann aber mit print bzw. echo einige Mühe...). PHP gibt die Zeilen außerhalb `<?php ... ?>` 1:1 zurück. Das mache ich mir zu nutze. Ausgaben im Terminal nach `chmod 755 fake404.cgi; ./fake404.cgi` ~~~ Status: 404 Content-Type:text/html; charset=utf-8 <h1>Hier wird ein 404er gefälscht.</h1> <hr> 2022-03-24 13:40:08 ~~~ ... abholen via Webserver: ~~~ < HTTP/1.1 404 Not Found < Date: Thu, 24 Mar 2022 12:45:52 GMT < Server: Apache/2.4.52 < Permissions-Policy: interest-cohort=() < Transfer-Encoding: chunked < Content-Type: text/html; charset=utf-8 < <h1>Hier wird ein 404er gefälscht.</h1> <hr> 2022-03-24 13:42:33 ~~~ ( `curl -v` markiert die Response-Headerzeilen mit vorangestelltem '< '). Das entspricht dem, was ich einst mit Perl lernte. Die erste leere Zeile im Ausgabestrom eines CGI-Skriptes trennt den HTTP-Header vom Payload (oft aber nicht immer: der Webseite). Es ist hier das **CGI-Modul des Webservers**, welches den Datenstrom entgegen nimmt und die HTTP-Header ersetzt bzw. ergänzt. **Also nicht PHP.** Übrigens ist eine Zeile mit dem Content-Type verpflichtend, sonst: „Error 500“. Dieses Problem wurde in Zeiten, als Perl/Cgi noch in Mode war, in diesem Forum ganz oft auf den Tisch gebracht... (Und schaut mal hier, in die alte Doku, die Google sehr gerne findet: http://www-hera-b.desy.de/subgroup/computing/IT/www/selfhtml/cgiperl/sprache/cginotwendig.htm) Insofern braucht sich niemand wundern, warum etwas wie *"Status: 404"* im PHP-Handbuch nicht vorkommt: PHP hat damit nichts zu tun. Im Apache Handbuch, den Seiten zu *-cgi, sollte aber dazu was stehen.

So. Ich habs: File: fake404.cgi ~~~PHP,bad #!/usr/bin/php Status: 404 Content-Type:text/html; charset=utf-8 <h1>Hier wird ein 404er gefälscht.</h1> <hr> <?php echo date('Y-m-d H:i:s');?> ~~~ (Das ist nicht im eigentlichen Sinne falsch, der Code funktioniert - **es soll nur keiner nachmachen**, der nicht meinen Test wiederholen will.) Die Programmiersprache ist egal, das würde mit Perl, Bash, Javascript (node.js), Python ... auch so klappen (ich hätte dann aber mit print bzw. echo einige Mühe...). PHP gibt die Zeilen außerhalb `<?php ... ?>` 1:1 zurück. Das mache ich mir zu nutze. Ausgaben im Terminal nach `chmod 755 fake404.cgi; ./fake404.cgi` ~~~ Status: 404 Content-Type:text/html; charset=utf-8 <h1>Hier wird ein 404er gefälscht.</h1> <hr> 2022-03-24 13:40:08 ~~~ ... abholen via Webserver: ~~~ < HTTP/1.1 404 Not Found < Date: Thu, 24 Mar 2022 12:45:52 GMT < Server: Apache/2.4.52 < Permissions-Policy: interest-cohort=() < Transfer-Encoding: chunked < Content-Type: text/html; charset=utf-8 < <h1>Hier wird ein 404er gefälscht.</h1> <hr> 2022-03-24 13:42:33 ~~~ ( `curl -v` markiert die Response-Headerzeilen mit vorangestelltem '< '). Das entspricht dem, was ich einst mit Perl lernte. Die erste leere Zeile im Ausgabestrom eines CGI-Skriptes trennt den HTTP-Header vom Payload (oft aber nicht immer: der Webseite). Es ist hier das **CGI-Modul des Webservers**, welches den Datenstrom entgegen nimmt und die HTTP-Header ersetzt bzw. ergänzt. **Also nicht PHP.** Übrigens ist eine Zeile mit dem Content-Type verpflichtend, sonst: „Error 500“. Dieses Problem wurde in Zeiten, als Perl/Cgi noch in Mode war, in diesem Forum ganz oft auf den Tisch gebracht... (Und schaut mal hier, in die alte Doku, die Google sehr gerne findet: http://www-hera-b.desy.de/subgroup/computing/IT/www/selfhtml/cgiperl/sprache/cginotwendig.htm) Insofern braucht sich niemand wundern, warum etwas wie *"Status: 404"* im PHP-Handbuch nicht vorkommt: PHP hat damit nichts zu tun. Im Apache Handbuch, den Seiten zu *-cgi, sollte aber dazu was stehen.

So. Ich habs: File: fake404.cgi ~~~PHP,bad #!/usr/bin/php Status: 404 Content-Type:text/html; charset=utf-8 <h1>Hier wird ein 404er gefälscht.</h1> <hr> <?php echo date('Y-m-d H:i:s');?> ~~~ (Das ist nicht im eigentlichen Sinne falsch, der Code funktioniert - **es soll nur keiner nachmachen**, der nicht meinen Test wiederholen will.) Die Programmiersprache ist egal, das würde mit Perl, Bash, Javascript (node.js), Python ... auch so klappen (ich hätte dann aber mit print bzw. echo einige Mühe...). PHP gibt die Zeilen außerhalb `<?php ... ?>` 1:1 zurück. Das mache ich mir zu nutze. Ausgaben im Terminal nach `chmod 755 fake404.cgi; ./fake404.cgi` ~~~ Status: 404 Content-Type:text/html; charset=utf-8 <h1>Hier wird ein 404er gefälscht.</h1> <hr> 2022-03-24 13:40:08 ~~~ ... abholen via Webserver: ~~~ < HTTP/1.1 404 Not Found < Date: Thu, 24 Mar 2022 12:45:52 GMT < Server: Apache/2.4.52 < Permissions-Policy: interest-cohort=() < Transfer-Encoding: chunked < Content-Type: text/html; charset=utf-8 < <h1>Hier wird ein 404er gefälscht.</h1> <hr> 2022-03-24 13:42:33 ~~~ ( `curl -v` markiert die Response-Headerzeilen mit vorangestelltem '< '). Das entspricht dem, was ich einst mit Perl lernte. Die erste leere Zeile im Ausgabestrom eines CGI-Skriptes trennt den HTTP-Header vom Payload (oft aber nicht immer: der Webseite). Es ist hier das **CGI-Modul des Webservers**, welches den Datenstrom entgegen nimmt und die HTTP-Header ersetzt bzw. ergänzt. **Also nicht PHP.** Übrigens ist eine Zeile mit dem Content-Type verpflichtend, sonst: „Error 500“. Dieses Problem wurde in Zeiten, als Perl/Cgi noch in Mode war in diesem Forum ganz oft auf den Tisch gebracht... (Und schaut mal hier, in die alte Doku, die Google sehr gerne findet: http://www-hera-b.desy.de/subgroup/computing/IT/www/selfhtml/cgiperl/sprache/cginotwendig.htm) Insofern braucht sich niemand wundern, warum etwas wie *"Status: 404"* im PHP-Handbuch nicht vorkommt: PHP hat damit nichts zu tun. Im Apache Handbuch, den Seiten zu *-cgi, sollte aber dazu was stehen.

So. Ich habs: File: fake404.cgi ~~~PHP #!/usr/bin/php Status: 404 Content-Type:text/html; charset=utf-8 <h1>Hier wird ein 404er gefälscht.</h1> <hr> <?php echo date('Y-m-d H:i:s');?> ~~~ Die Programmiersprache ist egal, das würde mit Perl, Bash, Javascript (node.js), Python ... auch so klappen (ich hätte dann aber mit print bzw. echo einige Mühe...). PHP gibt die Zeilen außerhalb `<?php ... ?>` 1:1 zurück. Das mache ich mir zu nutze. Ausgaben im Terminal nach `chmod 755 fake404.cgi; ./fake404.cgi` ~~~ Status: 404 Content-Type:text/html; charset=utf-8 <h1>Hier wird ein 404er gefälscht.</h1> <hr> 2022-03-24 13:40:08 ~~~ ... abholen via Webserver: ~~~ < HTTP/1.1 404 Not Found < Date: Thu, 24 Mar 2022 12:45:52 GMT < Server: Apache/2.4.52 < Permissions-Policy: interest-cohort=() < Transfer-Encoding: chunked < Content-Type: text/html; charset=utf-8 < <h1>Hier wird ein 404er gefälscht.</h1> <hr> 2022-03-24 13:42:33 ~~~ ( `curl -v` markiert die Response-Headerzeilen mit vorangestelltem '< '). Das entspricht dem, was ich einst mit Perl lernte. Die erste leere Zeile im Ausgabestrom eines CGI-Skriptes trennt den HTTP-Header vom Payload (oft aber nicht immer: der Webseite). Es ist hier das **CGI-Modul des Webservers**, welches den Datenstrom entgegen nimmt und die HTTP-Header ersetzt bzw. ergänzt. **Also nicht PHP.** Übrigens ist eine Zeile mit dem Content-Type verpflichtend, sonst: „Error 500“. Dieses Problem wurde in Zeiten, als Perl/Cgi noch in Mode war in diesem Forum ganz oft auf den Tisch gebracht... (Und schaut mal hier, in die alte Doku, die Google sehr gerne findet: http://www-hera-b.desy.de/subgroup/computing/IT/www/selfhtml/cgiperl/sprache/cginotwendig.htm) Insofern braucht sich niemand wundern, warum etwas wie *"Status: 404"* im PHP-Handbuch nicht vorkommt: PHP hat damit nichts zu tun. Im Apache Handbuch, den Seiten zu *-cgi, sollte aber dazu was stehen.

So. Ich habs: File: fake404.cgi ~~~PHP #!/usr/bin/php Status: 404 Content-Type:text/html; charset=utf-8 <h1>Hier wird ein 404er gefälscht.</h1> <hr> <?php echo date('Y-m-d H:i:s');?> ~~~ Die Programmiersprache ist egal, das würde mit Perl, Bash, Javascript (node.js), Python ... auch so klappen (ich hätte dann aber mot print bzw. echo einige Mühe...). PHP gibt die Zeilen außerhalb `<?php ... ?>` 1:1 zurück. Das mache ich mir zu nutze. Ausgaben im Terminal nach `chmod 755 fake404.cgi; ./fake404.cgi` ~~~ Status: 404 Content-Type:text/html; charset=utf-8 <h1>Hier wird ein 404er gefälscht.</h1> <hr> 2022-03-24 13:40:08 ~~~ ... abholen via Webserver: ~~~ < HTTP/1.1 404 Not Found < Date: Thu, 24 Mar 2022 12:45:52 GMT < Server: Apache/2.4.52 < Permissions-Policy: interest-cohort=() < Transfer-Encoding: chunked < Content-Type: text/html; charset=utf-8 < <h1>Hier wird ein 404er gefälscht.</h1> <hr> 2022-03-24 13:42:33 ~~~ ( `curl -v` markiert die Response-Headerzeilen mit vorangestelltem '< '). Das entspricht dem, was ich einst mit Perl lernte. Die erste leere Zeile im Ausgabestrom eines CGI-Skriptes trennt den HTTP-Header vom Payload (oft aber nicht immer: der Webseite). Es ist hier das **CGI-Modul des Webservers**, welches den Datenstrom entgegen nimmt und die HTTP-Header ersetzt bzw. ergänzt. **Also nicht PHP.** Übrigens ist eine Zeile mit dem Content-Type verpflichtend, sonst: „Error 500“. Dieses Problem wurde in Zeiten, als Perl/Cgi noch in Mode war in diesem Forum ganz oft auf den Tisch gebracht... (Und schaut mal hier, in die alte Doku, die Google sehr gerne findet: http://www-hera-b.desy.de/subgroup/computing/IT/www/selfhtml/cgiperl/sprache/cginotwendig.htm) Insofern braucht sich niemand wundern, warum etwas wie *"Status: 404"* im PHP-Handbuch nicht vorkommt: PHP hat damit nichts zu tun. Im Apache Handbuch, den Seiten zu *-cgi, sollte aber dazu was stehen.

So. Ich habs: File: fake404.cgi ~~~PHP #!/usr/bin/php Status: 404 Content-Type:text/html; charset=utf-8 <h1>Hier wird ein 404er gefälscht.</h1> <hr> <?php echo date('Y-m-d H:i:s');?> ~~~ Die Programmiersprache ist egal, das würde mit Perl, Bash, Javascript (node.js), Python ... auch so klappen (ich hätte dann aber mot print bzw. echo einige Mühe...). PHP gibt die Zeilen außerhalb `<?php ... ?>` 1:1 zurück. Das mache ich mir zu nutze. Ausgaben im Terminal nach `chmod 755 fake404.cgi; ./fake404.cgi` ~~~ Status: 404 Content-Type:text/html; charset=utf-8 <h1>Hier wird ein 404er gefälscht.</h1> <hr> 2022-03-24 13:40:08 ~~~ ... abholen via Webserver: ~~~ < HTTP/1.1 404 Not Found < Date: Thu, 24 Mar 2022 12:45:52 GMT < Server: Apache/2.4.52 < Permissions-Policy: interest-cohort=() < Transfer-Encoding: chunked < Content-Type: text/html; charset=utf-8 < <h1>Hier wird ein 404er gefälscht.</h1> <hr> ~~~ ( `curl -v` markiert die Response-Headerzeilen mit vorangestelltem '< '). Das entspricht dem, was ich einst mit Perl lernte. Die erste leere Zeile im Ausgabestrom eines CGI-Skriptes trennt den HTTP-Header vom Payload (oft aber nicht immer: der Webseite). Es ist hier das **CGI-Modul des Webservers**, welches den Datenstrom entgegen nimmt und die HTTP-Header ersetzt bzw. ergänzt. **Also nicht PHP.** Übrigens ist eine Zeile mit dem Content-Type verpflichtend, sonst: „Error 500“. Dieses Problem wurde in Zeiten, als Perl/Cgi noch in Mode war in diesem Forum ganz oft auf den Tisch gebracht... (Und schaut mal hier, in die alte Doku, die Google sehr gerne findet: http://www-hera-b.desy.de/subgroup/computing/IT/www/selfhtml/cgiperl/sprache/cginotwendig.htm) Insofern braucht sich niemand wundern, warum etwas wie *"Status: 404"* im PHP-Handbuch nicht vorkommt: PHP hat damit nichts zu tun. Im Apache Handbuch, den Seiten zu *-cgi, sollte aber dazu was stehen.