irishmann

function check(){
  let num = parseInt(document.getElementById('mynum').value);
  
  if (num > comp){
    out.innetHTML = 'Число больше';
  } else if (num < comp){
    out.innetHTML = 'Число меньше';
  } else{
    alert('win!!!');
  }
}

Редирект это 3xx, а ошибка это 5xx.
Вы не можете отдать два статуса одновременно.

Но вы можете отдав 500 отдать и содержимое страницы.

header('HTTP/1.1 500 Internal Server Error', true, 500);
readfile("my500page.html");

Никак не очищать.

На самом деле этот вопрос встречается довольно часто. Вот например популярный ответ на Stack Overflow, который подробно разбирает этот распространённое заблуждение: https://stackoverflow.com/a/3126175. И основная мысль там:

Понятие такой генерализованной "очистки данных" изначально бессмысленное и вредное.

Особенно такой вот индусской функцией, которая сама по себе - пример редкого идиотизма: сначала заменяем символы < и > на HTML сущности... а потом бодро пытаемся вырезать HTML теги. Которых к этому моменту в тексте не останется ни одного!
Или функция stripcslashes, которая здесь вообще ни к селу, ни к городу. Если я хочу написать сочетание \n, то с какой стати эта функция будет заменять его на перевод строки?
Всё что можно оставить из этого безумного набора - это trim(). Да и то не всегда. Как правильно заметил Rsa97, могут быть случаи, когда лидирующие пробелы имеют значение, например, при выводе форматированного кода. Кстати, этим как раз грешит Хабр. Если запостить код с отступами, то первый будет "съеден"!

Очистка

Любая "очистка" (хотя правильнее говорить про форматирование), имеет смысл только в определённом контексте.
И поэтому "очищать" надо только адресно, строго перед использованием в том или ином конкретном случае.

Например, базе данных ни жарко, ни холодно от наличия HTML тегов.
А проблемы могут начаться только при выводе данных в HTML. Но если мы будем предотвращать эти проблемы заранее, то просто попортим кучу данных. Поэтому форматировать данные для использования в контексте отрисовки HTML следет строго перед этой отрисовкой. То есть при выводе.
Что и делают все популярные РНР шаблонизаторы автоматически.
То есть вручную колупаться с "очисткой" вообще не нужно.

Больше того, "очистка" HTML поможет данным, выводимым в яваскрипт, как мёртвому припарки. То есть опять же - всегда надо понимать, в какой именно контекст мы выводим данные, и форматировать соответствующим образом. В частности любые данные передавать в яваскрипт только через json_encode()

И таких контекстов неисчислимое множество. Например, если мы используем переменную для передачи параметров в консольный скрипт, то надо обязательно обрабатывать её через escapeshellarg(). Если в регулярку - то preg_quote(). Имя файла для инклюда из переменной (хотя так делать вообще не стоит) надо хотя бы обрабатывать через basename(). И так далее.

Валидация

Если же наличие HTML тегов в поступающих данных противоречит техническому заданию, то надо заниматься не "очисткой", а валидацией: проверить регулярным выражением, есть ли в строке HTML теги. И если есть, то вернуть пользователю с сообщением об ошибке.

Защита БД

И кстати, по поводу "использую pdo".
На всякий случай уточню, что само по себе использование PDO не защищает ни от каких проблем
Важно помнить, что защита - это когда в базу данных отправляется строго константная строка запроса, полностью на 100% составленная из значений, прописанных в коде РНР, и в ней не используется ни одно значение, пришедшее в код извне. Причем PDO помогает здесь только наполовину, позволяя использовать в запросе подстановки вместо самих данных.
Но при этом для всех остальных частей запроса - например имен полей - у ПДО нет никакой защиты и её надо организовывать самостоятельно. Либо проверяя по белому списку, лабо, по крайней мере, прогоняя через регулярку.

1.

1. Результаты SQL запросов можно сохранить как csv, а потом импортировать в Excel
   
2. В современном Excel есть возможность импортировать данные прямо из БД. Посмотрите в райтере "Данные"
   

Свитч Auto MDI/MDIX, в него воткнуть все три двухпарных кабеля с прямой разводкой.

Вы сейчас пытаетесь строить то, что называется "коммутационный шкаф", в них два типа оборудования: патч-панели, на которые разводятся кабели от розеток на разъем типа RJ45 мама, и устройства организации локальной сети (свитчи, хабы, роутеры, вот это всё). Соответственно, минимум для локальной сети вам нужен свитч/хаб (конкретно хабов сейчас не делают, устарели), в который нужно воткнуть все три кабеля с помощью разъемов RJ45 папа.

Все, что попало в интернет – остается там навсегда!

Забудь, нет таких сервисов.

никак: это просто рекомендуемые настройки, а не реальные.

Это рекомендации. Причём я лично с ними не всегда соглашаюсь: например, для прода выставляю тоже E_ALL (но display_errors Off как и полагается), чтобы отлавливать редкие проблемы, не выявленные при разработке.

Вариант 1 - шаблонизаторы плюс рендер на стороне сервера
Вариант 2 - RESTful API на PHP а рендер на фронте по полученным данным

Вы конечно можете отдельно написать бек, а на фронт сделать на статическом HTML (потеряв при этом ряд возможностей, но представим, что они вам не нужны). Можете добавить на фронт js скриптов, которые будут что-то подгружать.
Никто не заставляет вас использовать php как шаблонизатор.

И нет, это не только php такой, практически в любом языке можно сделать такую-же кашу, просто в php эта возможность была изначально, и в первых версиях это был основной режим работы. А в других языках придётся это как-то включить, или написать промежуточный обработчик файлов.

Очевидно, чтобы быстро находить по uuid.

Короче, я боюсь, что, выучив слишком много всего, стану отпугивать работодателей своей продвинутостью.

лол
40 лет, а мыслит как 18-и летний юноша-максималист
выучит он "слишком много всего"
ты выучи сначала
потом приходи сюда
когда ты "слишком много всего" выучишь, тебе минимум будет 45 лет

Но вот думаю: А не слишком ли "крутым" я стану?

на первом же собеседовании тебя сотрет в порошок 25-30 летний чувак с опытом и покажет твое истинное место.
это не оскорбления.
это твое будущее.

btn_send.addEventListener('click',async() => {
    let blob = await new Promise(resolve => canvasElem.toBlob(resolve, 'image/png'));
    let formData = new FormData(); // Создаем объект формы для наполнения данными, словно мы работаем с тегом form в html.
    formData.append('canvas_field', blob, 'canvas.png'); // это эквивалент тому, что в нашей html форме создаем поле input type="file" name="canvas_field" value="canvas.png" и прикрепляем туда содержимое blob (метод append сам расшаривает blob, дополнительных преобразований не требуется). Естественно, на DOM-дереве это никак не отразится, это модель формы в памяти JS.
    let response = await fetch('web_tp_word.php', {
    method: 'POST',
    body: formData // для fetch не нужно дополнительных параметров, чтобы объяснить как работать с formData. Идеально, чтобы завернуть файл в форму и отправить на сервер.
    });
});

На стороне сервера:

var_dump($_FILES['canvas_field']); // Сервер при вызове скрипта сложит данные файла во временный файл, а как их получить - в $_FILES. Далее можно обрабатывать всеми теми способами, предназначенные для работы с $_FILES. И после уже неважно, как их сгенерировали на клиенте.