irishmann

Если вы выведете какой-нибудь текст до заголовка, то header уже не сможете отправить.
Если отправите header Location, то в браузере произойдёт редирект, и все что выводится после редиректа будет проигноровано.

Вам бы всю схему пересмотреть.

Если привязать бэк к конкретному часовому поясу, тогда в разных частях планеты будет разное время обновления, что не очень приятно.

1. Зато одновременно у всех.
2. Пользователь не знает какое время у сервера, не знает во сколько сброс. Ему надо сообщить во сколько будет сброшена статистика и основываясь на этих данных, он подберет удобное для себя время.

Еще можно для каждого пользователя завести его личный таймер. Принцип тот-же.

Никто не запрещает использовать kohana\core как отдельную библиотеку, hmvc реализуется на большинстве фреймворков, например на yii. Это же паттерн, он не привязан к какому-либо фреймворку.

enctype="multipart/form-data"
В аттрибут формы. Гуглится за 1.5 минуты.

Upd. Не увидел что вы полностью отправляете на JS.

Насчёт загрузки файлов не уверен что сработает serialize
Используйте FormData()

Ваш провайдер имеет аплинки к другим провайдерам (зачастую к трансмагистральным провайдерам, которые лично владеют коммуникационными каналами на далекие расстояния - например провайдер сам является международным и у него есть оптические каналы проложенные к его датацентрам в других странах, либо у двух крупных провайдеров есть какой-то канал, который они вместе построили и проложили под землей или через океан. Там вообще могут быть коммуникации купленные вскладчину несколькими участниками.

Стоимость прокладки таких каналов стоят огромных денег. Это и непосредственно сами работы и огромное количество разрешений на эти работы, которые должны быть согласованы со всеми владельцами и странами. Поэтому окупается это так, что между провайдерами всегда идут какого-то рода взаиморасчеты за передачу траффика. Кто генерит контент, то собственно больше и получает, кто скачивает - тот платит.
Но стоимость этих взаиморасчетов может быть разная на разном уровне. Где-то определенный объем входит в абонплату. Где-то трафик ночью дешевле. Где-то можно сделать дешевле но медленнее. Условия разные и гибкие.
Поэтому в свитчах провайдеров всегда настроены довольно сложные правила и для минимизации этой цены, и для обеспечения отказоустойчивости (если какой-то маршрут нарушен, автоматом может пустить по другому каналу, возможно более медленному). Плюс ошибки админов.

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

Также из всей сложной схемы и могут возникать такие ситуации, когда, например трафик из Украины в Россию, дешевле будет пускать не напрямую, а через Франкфурт, хотя казалось бы напрямую будет короче.

Так и живем.

P.S. Ах да, еще - пинг и скорость это разные показатели, не всегда релевантно относящиеся друг с другом, но в отдельных моментах ширина канала может аффектить пинг. Если посчитать скорость света с минимальной затратой на проход пакета через маршрутизаторы, можно сказать что самый большой пинг в пределах Земли должен быть около 400 мс между точками-антиподами. Но тут естественно нужно учитывать между этими точками только оптика, или что-то еще.

P.P.S. хорошая статья на Хабре от amarao https://habr.com/ru/post/186282/

seagate 2012 года на терабайт, при подключении головка бегает туда-сюда некоторое время, затем диск отключается

У дисков Сигейт такие симптомы (щелчки / клики, затем остановка двигателя) означают выход из строя головок. Очень часто с повреждением магнитной поверхности пластин той или иной степени.

Диск явно подвергался пыткам во время работы: на блине есть отчётливая царапина и несколько точечных царапин.

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

Говоря в целом, вы очень зря вскрыли гермоблок жёсткого диска. Даже если бы на блинах не было царапин, это сделало бы ситуацию хуже, а стоимость восстановления данных - выше.

Что можно попробовать сделать, чтобы диск запустился и хоть что-то с него попытаться вытащить? Контакты платы уже почищены до блеска

Уж простите мой сарказм, но это примерно как спросить врача: "Человек на спорткаре влетел в столб на скорости 250 км/ч. Наклеили ему на лоб аж три лейкопластыря, как ещё можно попробовать его подлечить?"

Сами вы не сделаете уже ничего. Контакты на плате здесь совершенно не при чём.
Класть диск в холодильник и менять плату - тоже не поможет.
Диск нужно тщательно очищать от магнитной пыли внутри и менять блок головок. Скорее всего, не один раз.
А с учётом описания ситуации, не факт, что в таком состоянии его получится запустить вообще.

этот диск ни в какой специализированный дорогой сервис относить не будет

Тогда всё. Такой случай (концентрические царапины, вскрытие) требует специалиста по восстановлению информации очень высокой квалификации. А те, кто умеют работать с такими случаями, расстроят вас ценой и сроками.

Написано что сохранено в дампе. Чем его прочитать?

https://www.nirsoft.net/utils/blue_screen_view.html

https://webwormhole.io/

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 есть возможность импортировать данные прямо из БД. Посмотрите в райтере "Данные"