304 - обычно не ошибка, а даже наоборот - правильный ответ сервера. Просто сообщает клиенту, что документ с последнего посещения не менялся и повторно выкачивать его не надо.
skAmZ: Стандарты для того и создаются, чтобы ввести единообразие. Если каждый будет писать, как ему вздумается, будет каша.
Стандарт, как раз и предусматривает, что числовой код отдается для машин, а текстовое описание кода - для людей. А люди, которые пишут поисковые роботы, поверьте, очень хорошо разбираются в стандартах. :)
Лет 5 назад я держал корпоративную базу mysql на ram-диске, только причина была другой - тогда модны были внезапные налеты налоговых инспекций с выключением электропитания, чтоб менеджеры ничего не успели удалить с хардов :) ну и начальство переживало по этому поводу. Бекапы дампа базы делались где-то раз в час в инет, на "засекреченный сайт". Ну а скорость работы с базой была действительно почти фантастичной. Риски менеджеров - пропажа данных за последний час работы, фигня вообщем.
maximus200: Есть еще и такой быстрый способ смены паролей, которые в зашифрованом виде есть лежат в базе. 1. Зная лог и пас какого-то пользователя (П) заходим в базу. 2. Копируем хеш код этого П и вставляем его нужному юзеру (Ю). 3. Теперь у Ю такой же пасс как и у известного нам П. 4. Логинимся под этим Ю используя пасс от П. Энджой.
в vBulettin этот способ не сработает 🚬
Если быть точным, сработает, если помимо поля password таблицы user (где содержится хэш пароля), утащить еще значение поля salt и уже Ю поменять оба поля.
304 - обычно не ошибка, а даже наоборот - правильный ответ сервера. Просто сообщает клиенту, что документ с последнего посещения не менялся и повторно выкачивать его не надо.
Как можно его поменять?
а зачем его менять? только если ради понтов.. 😕
Почему вы так думаете?)
сталкивался..
Стандарты для того и создаются, чтобы ввести единообразие. Если каждый будет писать, как ему вздумается, будет каша.
Стандарт, как раз и предусматривает, что числовой код отдается для машин, а текстовое описание кода - для людей. А люди, которые пишут поисковые роботы, поверьте, очень хорошо разбираются в стандартах. :)
Корректностью. "301 OK" - не корректный вариант.
Вполне корректный, ибо "The reason phrases listed here are only recommendations -- they MAY be replaced by local equivalents without affecting the protocol." http://www.w3.org/Protocols/rfc2616/rfc2616-sec6.html#sec6.1.1
Лет 5 назад я держал корпоративную базу mysql на ram-диске, только причина была другой - тогда модны были внезапные налеты налоговых инспекций с выключением электропитания, чтоб менеджеры ничего не успели удалить с хардов :) ну и начальство переживало по этому поводу. Бекапы дампа базы делались где-то раз в час в инет, на "засекреченный сайт". Ну а скорость работы с базой была действительно почти фантастичной. Риски менеджеров - пропажа данных за последний час работы, фигня вообщем.
.. и не сочтите за трудность лишний раз проверить творение валидатором: http://validator.w3.org/ 🚬
что это может быть?
это могут быть индексы на больших таблицах.. за все нужно платить
Есть еще и такой быстрый способ смены паролей, которые в зашифрованом виде есть лежат в базе.
1. Зная лог и пас какого-то пользователя (П) заходим в базу.
2. Копируем хеш код этого П и вставляем его нужному юзеру (Ю).
3. Теперь у Ю такой же пасс как и у известного нам П.
4. Логинимся под этим Ю используя пасс от П.
Энджой.
в vBulettin этот способ не сработает 🚬
Если быть точным, сработает, если помимо поля password таблицы user (где содержится хэш пароля), утащить еще значение поля salt и уже Ю поменять оба поля.
Прошу прощения, но это 100% точно?
Вы так сами делали?
*мне это важно знать*
это абсолютно точно, мыло меняется прямо в базе, в таблице {PREFIX}user, поле называется email 🚬
Вообщем-то админ может поменять мыло и из админ-панели напрямую.. а возможно оттуда же можно прямо и пароль сменить, лень смотреть.