ugodrus

Ничего удивительного. Вы передаете переменную через ГЕТ key=1
Внутри PHP $_SERVER['REQUEST_URI'] = /login/?key=1
Далее по коду

$page = 'login/?key=1'; 
if (file_exists("all/login/?key=1.php")) 
  include "all/login/?key=1.php"; 
  else if ($_SESSION['logged_user'] and file_exists("auth/login/?key=1.php"))
  include "auth/login/?key=1.php";
  else if (!$_SESSION['logged_user'] and file_exists("guest/login/?key=1.php"))
  include "guest/login/?key=1.php";
  else
  header('Location: /404');

Не думаю что у вас в auth/login/ найдется файл ?key=1.php
Не знаю с каких времён у вас такая дремучая конструкция. Такие городулины со времени похорон 4.3 не практиковал и не встречал.
Вердикт один - либо подбирайте другую переменную с корректным значением $page. Либо чистите эту. Убирая лишнее и анализируя подходит ли значение после фильтрации.

Без примера данных тяжело сказать. Вообще Json у вас там читается? Попробуйте поиграться с опциями json_encode может быть дело в экранировании каких-нибудь символов.

Нашел кое-что на тему curl can't open Unicode filenames in Windows.

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

Проблема не зависит от ОС. На Linux тот же эффект. Проблема возникает при сборке запроса перед его отправкой. Старый вариант подключения файлов через "@filepath" тоже не подгружает данные, но хотя бы пытается отправить запрос с указанием передаваемых файлов, но пустых.

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

Вообще тема нужная как раз для этих "макак". Но это уже не тема хабра и тостера, поскольку тема была уже сотни раз приготовлена, съедена и переварена.

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

В нете куда больше всяких трюков по оптимизации кода, а данный пример действительно ни о чём. Если действительно хотите помочь новичкам - не занимайтесь трюками на минимальном левеле php с циклами и операторами. Примеров оптимизации в этой теме больше чем достаточно. Копайте в сторону ООП. Там гораздо больше чудес кроется. По многим примерам в нете тяжело что-то найти.
Кое-какие эксперименты и сам делал. И соответственно делал выводы что лучше использовать а что категорически нельзя.

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

А по циклам вообще. Максимальные циклы за мою практику for и foreach до 300, while до 50 000.

Сам одно время пробовал парсить результат выдачи яндекса. Поверьте моему опыту - парсить живой (не xml) результат поиска - сломанный костыль. Часто меняются элементы разметки и бан идёт регулярный, хотя я пользовался сокетами и имитировал браузер на 100%. После 2х месяцев геморроя сам прикрыл лавочку.
Мой совет - ковыряйте XML выдачу.

В принципе можно попробовать через Files или FilesMatch методом от обратного. Но на мой взгляд лучше просто переложить защищаемый контент.

Демон - мне кажется слишком громко сказано. Демону надо ещё умудриться скормить большой файл. Да ещё и указать что с ним сделать. Вы наверное пользуетесь стандартной xml библиотекой и соответственно большой файл обваливает интерпретатор.
Очень рекомендую покопать в сторону самодельного парсера. Как пример в PHP есть XML parser. При скромных потребностях на нем можно распарсить хоть 10Gb xml при потреблении памяти до 10mb. Главное чтобы по времени ограничений не было.
Пример реализации здесь.
Я себе что-то похожее собирал. Но не как полноценный парсер, а как утилиту первичного разбора xml для последующей обработки вне её и с поддержкой своего рода запросов (сделать что-то с элементами у которых определенный node-path). Разбирал максимум 100mb xml.

Была такая проблема. Через дырку в старой CMS размещали скрипты для рассылки Мылом. Зная что в CMS только две точки входа написал правило через mod_rewrite
Если метод запроса - POST и файл к которому обращаются - не один из этих двух, то показать ему кукиш.
Это на перифирии. А также, поставил запреты на доступ ко всем административным папкам, контент которых инклудится. И в конце отыскал все скрипты в которых используется eval(). И все их проверил на иньекции кода. Помогло. Хотя боты до сих пор стучатся.

Если вам так не терпится получать JSON из БД то полистайте вот это.
Вообще сам по себе такой принцип хорош ( извлечение данных в Json ), но только не в кривых руках. Я использовал такое в интернет магазине для выборки товаров. Реально выгоднее по скорости запросов. Чуть тормознутей обычного селекта, но куда быстрей целой серии запросов. Но хранить в Json на мой взгляд уместно лишь небольшие клочки данных. Фрагменты конфигов например.

Всё зависит от реализации связки PHP Apache. Напимер в режиме fcgi PHP не работает с директивами в htaccess и единственная возможность на него повлять - подключение дополнительных ini файлов.
Работаю с ISPmanager. В нем под каждый модуль доступный для всех пользователей на сервере свой ini файл. И это очень удобно - не надо долго искать настройки. Также имеется конфиг для конкретного пользователя, от имени которого запускаются скрипты. Там меняются дефолтные настройки всего сервера под конкретного пользователя.

function downloadFile ($URL, $PATH) {
    $ReadFile = fopen ($URL, "rb");
    if ($ReadFile) {
        $WriteFile = fopen ($PATH, "wb");
        if ($WriteFile){
            while(!feof($ReadFile)) {
                fwrite($WriteFile, fread($ReadFile, 4096 ));
            }
            fclose($WriteFile);
        }
        fclose($ReadFile);
    }
}

Метод отлично работает на больших объемах.
Можете также реализовать через сокеты. Тоже няшка получается.

Вот так.

@dez-fafara: Несколько некорректный ответ. Если посмотреть как отражается сессия в COOKIE то сессия представляет собой пару Ключ -> Значение. Где Ключ - это имя сессии, а Значение - её уникальный номер в системе, тоторый обычно создается через md5 алгоритм по времени инициализации сессии. В среде PHP ключ ( или имя сессии ) - это наименование переменной окружения в которой хранится уникальный номер сессии. По умолчанию Имя сессии в PHP - PHPSESSID. Функции session_name() и session_id() работают с Именем сессии и её номером. Обе могут принимать новые значения и отдавать текущие (запуск функций с параметром и без). Обе должны быть вызваны до начала работы с данными сессии. Их можно и не трогать, если настройки по умолчанию для хранения сессий вас устраивают, поскольку session_start() самостоятельно присваивает как имя, так и идентификатор сессии. Если данных о сессии нет (переменной с именем сессии не установлено) то создается новый Id. Если переменная есть, то session_start() продолжает вести уже существующую сессию.

Я бы посоветовал прислушаться к совету Александра Александровича. Это будет мудрее. Или же сделать через mod_rewrite но в обход скрипта. Т.е. уже на уровне Apache перенаправлять на запрашиваемый URL. Это уже вопрос повышения производительности.

1) Для начала хотелось бы увидеть весь запрос.
2) использование LIKE и прочей бурды в JOIN ON не рекомендуется.
3) Возможно вам стоит переложить запрос без Join по такому принципу
SELECT something FROM price t1, price t2 WHERE и здесь указать правила соединения таблиц и прочие условия
но не зная конечный запрос сказать тяжело.

Проблемы не вижу вообще. Единственная проблема - при переезде сайта. Приходится менять конфиги в корне, манагере, коннекторах. Но в остальном жесткие пути это наоборот благо. Мне часто приходится делать модули с API системы и подключать их при жестких маршрутах легче. Попробуйте вернуться к EVO и увидите какой там был косяк с маршрутами. Каждый модуль ссылался по своему. Зато сейчас любо-дорого смотреть.

Если количество результатов по условию достаточно велико, то соответственно вычисляется много случайных чисел для этих полей. И LIKE я лично не использую никогда - очень тупой метод.. а когда с большими объёмами работает - вообще мрак. Попробуйте переделать под REGEX и если набор выбранных данных всегда достаточно большой - лучше переделать по другому. Советую заглянуть сюда.