Забавно. Только что поставил эксперимент, использовал 3 браузера - IE7, FF2 и Opera 9.27. Результаты, мягко скажем, неожиданные, и отличается от того, что в спецификации:
1. IE и FF позволяют работать с 50 куками (парами ключ-значение).
2. Opara позволяет работать только с 30 куками.
3. Все три браузера принимают куки, суммарный размер которых больше чем 4 килобайта (как раз максимум по 4 килобайта на каждую, как в спеке), и сохраняет их на диске в полном объеме.
4. Opera, когда посылает респонс, отправляет куки серверу только пока суммарный их размер не превышает 4 килобайта. Если суммарный размер кук больше, то отправляются только первые из них, суммарный размер которых в пределах 4 килобайт.
5. IE и FF пытаются отправить серверу все куки что есть, игнорируя размеры. При этом сервер (в моем случае Apache 1.3) ругается на неправильный заголовок, мол, превышен размер.
Итак, вывод из этой лабораторной работы. Спека - это одно, а на практике оказывается, как обычно, производители браузеров ей не очень следуют.
А вот насчет последнего я не уверен. Как тогда это понимать (из того же пункта 6.3, кстати это цитируется в приведенной Вами ссылке): "at least 20 cookies per unique host or domain name"? Как раз это и сбивает с толку, и вносит путаницу что они называют термином cookie - то ли одну пару ключ-значение, то ли "всю сессионную информацию"?
Спасибо за ссылку, признаю свою неправоту. Спека, которой я пользовался, http://www.w3.org/Protocols/rfc2109/rfc2… (пункт 6.3) не говорит об этом прямо, и лишь дополнительная информация по приведенной Вами ссылке проясняет этот момент.
> но ограничение хранения данных в размере не более 2kb не всех радует, сегодня если позволите я вам расскажу как посредством Java Script хранить около 100kb на клиенте.
Во-первых, ограничение не 2Kb, а 4Kb на куку. Во-вторых, на одном домене можно одновременно иметь до 20 кук включительно. Итого, суммарно, можно, используя механизм Cookies, оперировать 80Kb. А еще можно сжимать данные, таким образом хранить больший объем данных в этих доступных 80Kb.
Но в любом случае я согласен, что большие объемы данных в куках держать глупо, так как все эти данные будут отправляться на сервер при каждом реквесте.
Ну что же, жаль что не поняли. И еще более жаль читать фразы типа Вашей: "автор, похоже, слабо представляет, о чем пишет", которые некоторые сначала пишут, а потом начинают разбираться в вопросе.
Хотя тут еще возможно, что я, будучи начинающим автором, недостаточно четко изложил свою мысль, и тем, кто статью прочитал, было не все интуитивно понятно. То есть мне в есть над чем работать... Ну ладно, надеюсь, может быть хоть кому-то данная статья оказалась полезной.
Программа действительно должна включать в себя логику восстановления после сбоя в работе, с этим никто не спорит. Но минимизировать возможность потери (пусть и временной) своих данных, особенно конфигов, не менее важно.
Приведу пример. Скажем, у Вас есть скрипт, который при каждом реквесте обращается к конфигу на чтение, то есть очень-очень часто. Один из процессов иногда, сравнительно редко, вносит в этот конфиг какие-то изменения. Допустим, при очередном изменении конфига, приозошел сбой, и в конфиге оказались не все данные, которые там должны быть. Получается, пока не произойдет восстановления из бакапа (а в данном случае нужно будет еще и распознать, что в конфиге не все что нужно), скрипт будет работать неправильно с запорченным конфигом, что может привести к печальным последствиям.
Вот как раз описанный мной способ и минимизирует возможность порчи изменяемого файла. Соответственно, система работает более устойчиво. А восстановление после сбоя - это отдельная логика, не является частью данной статьи, так как речь сейчас не об этом.
Ведь согласитесь, что лучше не восстанавливать свою систему после сбоя, а просто запустить ее чтобы она продолжила работу как ни в чем ни бывало, если это конечно возможно, и сбой не фатальный.
В своей статья я умышленно не затронул вопрос копий (bak). Это обычно само собой подразумевается, причем, часто делается не одна копия, а несколько, с ротацией версий. Но к теме это отношения не имеет.
Повторюсь. Делать копию - недостаточно. Нужно еще и минимизировать возможное появление вероятных проблем. Если Вы сделали копию, и пишите прямо в файл, и скрипт умер по сигналу, то что будет с файлом? Он может быть нулевым, или записанным не полностью. Вам придется добавлять довольно сложную логику по проверке целостности этого файла при каждом обращении к нему, возможно, писать дополнительный скрипт для автоматического восстановления из bak-копии (а то система будет полностью неработоспособна все то время, пока, например, конфиг запорчен), и т.д. Думайте, пожалуйста.
Если Вы планируете вручную делать восстановление после возможного сбоя, то вариант с bak достаточен. Но если Вы хотите минимизировать возможность сбоя, то этот способ не является достаточным.
В своей практике я постоянно использую bak файлы, но данная статья была не об этом, а о минимизации ситуаций, когда возможна порча файла, в который делается запись. bak-файл не помогает в этом никак, к сожалению.
Написать-то свою логику для обработки некоторых исключительных ситуации можно. Но увы, не всегда эта логика может работать. Например, какой логикой сможете защититься от смерти скрипта, например, при выключении питания компьютера?
Пример. Открыли файл на запись, начали в него писать, и тут вдруг скрипт умер. Что случится с файлом? Очень большая вероятность, то он будет или нулевого размера, или вообще запорчен. А если это был конфиг, то работать проект уже не сможет, конфиг-то запорчен.
Я так и знал что Вы это напишите. И не могу не согласиться, Вы правы.
Именно поэтому не стоит лишать пермиссий на создание файлов директорию, в которой расположен файл, который нужно изменять.
Впрочем, все равно такое сохранение копии + "неатомарное" перемещение лучше, чем просто прямая запись в файл.
Ведь при прямой записи в файл в случае исключительной ситуации мы теряем данные навсегда, а при копировании из копии при исключительной ситуации как минимум остается эта сама копия, из которой файл может быть потом восстановлен. То есть это все равно надежнее.
Но в любом случае, не поймите меня неправильно, хоть этот способ с пермиссиями и надежнее, это все же частный случай, которого желательно избегать.
Спасибо, подловили! Но я все же попробую доказать свою точку зрения.
Все дело в термине "переименование". Функция rename, которую Вы используете, работает так - удаляет предыдущий файл, и заменяет новым. Это функция низкоуровневая, и используя только ее действительно невозможно переименовать файл в директорию, пермиссии которой не дают возможности создавать новые файлы.
Но есть и другие способы переименования (точнее сказать, переноса).
Это более сложные способы, при которых используется rename, и, если rename сделать невозможно, то производится перекачка данных из файла-источника в файл в закрытой директории, с последующим удалением файла-источника.
Как пример, так работает функция move модуля File::Copy языка Perl. Вот, показываю:
$ ls -l a
-rw-r--r-- 1 tvv tvv 1 Jul 14 19:33 a
$ ls -ld b
dr-xr-xr-x 2 tvv tvv 4096 Jul 14 19:27 b
$ ls -l b/c
-rw-r--r-- 1 tvv tvv 0 Jul 14 19:27 b/c
$ perl -e "use File::Copy; move('a','b/c')"
$ ls -l a
ls: a: No such file or directory
$ ls -l b/c
-rw-r--r-- 1 tvv tvv 1 Jul 14 19:33 b/c
А вот слово "бред" тут IMHO неуместно. Единственная моя ошибка, точнее, опечатка, что я использовал слово "переименование" вместо сходного слова "перенос". Тактичнее, тактичнее...
В моем случае, если нет свободного места, то новый конфиг создан не будет, а старый конфиг останется целым. В Вашем же случае конфиг станет файлом нулевой длины. Не верите - проверьте.
Но вообще, случай с местом на диске - это лишь один вариант исключительной ситуации из десятков. Понимаете, при любой исключительной ситуации в процессе записи в Вашем случае, например, если скрипт просто прервет работу при записи, будет тот же самый плачевный результат - получится файл нулевой длины. В моем же случае старый конфиг останется цел.
База данных. Если нет места на диске, может вести себя по-разному, но данные однозначно не будут потеряны, а в Вашем - будут. Заметьте, я не призываю использовать именно базу данных, но, если нужна надежность, при условии конкурентного доступа использовать ее однозначно предпочтительнее, чем Ваше решение.
Пожалуйста, все же пробуйте рассмотреть ситуацию более глубоко, и не спешите писать обвинения в невежестве, я все это прошел уже лет 15 назад, и тоже в свое время допускал те же самые ошибки.
Прежде чем обвинять меня в незнании азов, сначала ответьте пожалуйста на вопрос, который я задал выше. Что будет с файлом, если Вы сделали flock, пишите в этот файл, и тут произошла исключительная ситуация и Ваш скрипт прервал работу?
Далее. Я не говорил что файловая система не предназначена для хранения. С чего Вы такое взяли? Как раз наоборот, файловая система предназначена исключительно для хранения файлов, но не более чем. Я лишь утверждаю, что файловая система сама по себе не предназначена для безопасного управления файлами при условии конкурентного доступа на запись к одним и тем же файлам со стороны разных процессов. Она слишком низкоуровнева для этого, по определению.
Большинство языков программирования включают в себя функции или методы, которые сразу позволяют задавать пермиссии при создании нового файла. Но в статья я это не упомянул, так как не везде это нужно делать (например, для Windows Desktop applications).
Про права директории на создание-удаление файлов. Если Вы имеете в виду Unix/Linux, то там все устроено так. Если права директории не позволяют создавать в ней файлы, но один из файлов имеет права на запись, то можно в другой, временной директории создать новый файл, затем переименовать его в ту закрытую для создания файлов директорию, заменив старый. То есть проблем в нашем случае - не будет, это и теоретически так, и на практике проверено неоднократно.
Мое мнение - если есть конфигурационный файл, и много процессов его могут изменять одновременно, то в этом случае лучше вообще отказаться от использования конфигурационного файла в пользу базы данных, или другого специализированного механизма.
Описанный мной в статье пример в первую очередь актуален для систем, которые пишут в файл только из одного процесса, например, Desktop applications.
1. IE и FF позволяют работать с 50 куками (парами ключ-значение).
2. Opara позволяет работать только с 30 куками.
3. Все три браузера принимают куки, суммарный размер которых больше чем 4 килобайта (как раз максимум по 4 килобайта на каждую, как в спеке), и сохраняет их на диске в полном объеме.
4. Opera, когда посылает респонс, отправляет куки серверу только пока суммарный их размер не превышает 4 килобайта. Если суммарный размер кук больше, то отправляются только первые из них, суммарный размер которых в пределах 4 килобайт.
5. IE и FF пытаются отправить серверу все куки что есть, игнорируя размеры. При этом сервер (в моем случае Apache 1.3) ругается на неправильный заголовок, мол, превышен размер.
Итак, вывод из этой лабораторной работы. Спека - это одно, а на практике оказывается, как обычно, производители браузеров ей не очень следуют.
Во-первых, ограничение не 2Kb, а 4Kb на куку. Во-вторых, на одном домене можно одновременно иметь до 20 кук включительно. Итого, суммарно, можно, используя механизм Cookies, оперировать 80Kb. А еще можно сжимать данные, таким образом хранить больший объем данных в этих доступных 80Kb.
Но в любом случае я согласен, что большие объемы данных в куках держать глупо, так как все эти данные будут отправляться на сервер при каждом реквесте.
Хотя тут еще возможно, что я, будучи начинающим автором, недостаточно четко изложил свою мысль, и тем, кто статью прочитал, было не все интуитивно понятно. То есть мне в есть над чем работать... Ну ладно, надеюсь, может быть хоть кому-то данная статья оказалась полезной.
Приведу пример. Скажем, у Вас есть скрипт, который при каждом реквесте обращается к конфигу на чтение, то есть очень-очень часто. Один из процессов иногда, сравнительно редко, вносит в этот конфиг какие-то изменения. Допустим, при очередном изменении конфига, приозошел сбой, и в конфиге оказались не все данные, которые там должны быть. Получается, пока не произойдет восстановления из бакапа (а в данном случае нужно будет еще и распознать, что в конфиге не все что нужно), скрипт будет работать неправильно с запорченным конфигом, что может привести к печальным последствиям.
Вот как раз описанный мной способ и минимизирует возможность порчи изменяемого файла. Соответственно, система работает более устойчиво. А восстановление после сбоя - это отдельная логика, не является частью данной статьи, так как речь сейчас не об этом.
Ведь согласитесь, что лучше не восстанавливать свою систему после сбоя, а просто запустить ее чтобы она продолжила работу как ни в чем ни бывало, если это конечно возможно, и сбой не фатальный.
Повторюсь. Делать копию - недостаточно. Нужно еще и минимизировать возможное появление вероятных проблем. Если Вы сделали копию, и пишите прямо в файл, и скрипт умер по сигналу, то что будет с файлом? Он может быть нулевым, или записанным не полностью. Вам придется добавлять довольно сложную логику по проверке целостности этого файла при каждом обращении к нему, возможно, писать дополнительный скрипт для автоматического восстановления из bak-копии (а то система будет полностью неработоспособна все то время, пока, например, конфиг запорчен), и т.д. Думайте, пожалуйста.
В своей практике я постоянно использую bak файлы, но данная статья была не об этом, а о минимизации ситуаций, когда возможна порча файла, в который делается запись. bak-файл не помогает в этом никак, к сожалению.
Пример. Открыли файл на запись, начали в него писать, и тут вдруг скрипт умер. Что случится с файлом? Очень большая вероятность, то он будет или нулевого размера, или вообще запорчен. А если это был конфиг, то работать проект уже не сможет, конфиг-то запорчен.
Согласны?
Именно поэтому не стоит лишать пермиссий на создание файлов директорию, в которой расположен файл, который нужно изменять.
Впрочем, все равно такое сохранение копии + "неатомарное" перемещение лучше, чем просто прямая запись в файл.
Ведь при прямой записи в файл в случае исключительной ситуации мы теряем данные навсегда, а при копировании из копии при исключительной ситуации как минимум остается эта сама копия, из которой файл может быть потом восстановлен. То есть это все равно надежнее.
Но в любом случае, не поймите меня неправильно, хоть этот способ с пермиссиями и надежнее, это все же частный случай, которого желательно избегать.
Все дело в термине "переименование". Функция rename, которую Вы используете, работает так - удаляет предыдущий файл, и заменяет новым. Это функция низкоуровневая, и используя только ее действительно невозможно переименовать файл в директорию, пермиссии которой не дают возможности создавать новые файлы.
Но есть и другие способы переименования (точнее сказать, переноса).
Это более сложные способы, при которых используется rename, и, если rename сделать невозможно, то производится перекачка данных из файла-источника в файл в закрытой директории, с последующим удалением файла-источника.
Как пример, так работает функция move модуля File::Copy языка Perl. Вот, показываю:
$ ls -l a
-rw-r--r-- 1 tvv tvv 1 Jul 14 19:33 a
$ ls -ld b
dr-xr-xr-x 2 tvv tvv 4096 Jul 14 19:27 b
$ ls -l b/c
-rw-r--r-- 1 tvv tvv 0 Jul 14 19:27 b/c
$ perl -e "use File::Copy; move('a','b/c')"
$ ls -l a
ls: a: No such file or directory
$ ls -l b/c
-rw-r--r-- 1 tvv tvv 1 Jul 14 19:33 b/c
А вот слово "бред" тут IMHO неуместно. Единственная моя ошибка, точнее, опечатка, что я использовал слово "переименование" вместо сходного слова "перенос". Тактичнее, тактичнее...
Но вообще, случай с местом на диске - это лишь один вариант исключительной ситуации из десятков. Понимаете, при любой исключительной ситуации в процессе записи в Вашем случае, например, если скрипт просто прервет работу при записи, будет тот же самый плачевный результат - получится файл нулевой длины. В моем же случае старый конфиг останется цел.
База данных. Если нет места на диске, может вести себя по-разному, но данные однозначно не будут потеряны, а в Вашем - будут. Заметьте, я не призываю использовать именно базу данных, но, если нужна надежность, при условии конкурентного доступа использовать ее однозначно предпочтительнее, чем Ваше решение.
Пожалуйста, все же пробуйте рассмотреть ситуацию более глубоко, и не спешите писать обвинения в невежестве, я все это прошел уже лет 15 назад, и тоже в свое время допускал те же самые ошибки.
Далее. Я не говорил что файловая система не предназначена для хранения. С чего Вы такое взяли? Как раз наоборот, файловая система предназначена исключительно для хранения файлов, но не более чем. Я лишь утверждаю, что файловая система сама по себе не предназначена для безопасного управления файлами при условии конкурентного доступа на запись к одним и тем же файлам со стороны разных процессов. Она слишком низкоуровнева для этого, по определению.
Про права директории на создание-удаление файлов. Если Вы имеете в виду Unix/Linux, то там все устроено так. Если права директории не позволяют создавать в ней файлы, но один из файлов имеет права на запись, то можно в другой, временной директории создать новый файл, затем переименовать его в ту закрытую для создания файлов директорию, заменив старый. То есть проблем в нашем случае - не будет, это и теоретически так, и на практике проверено неоднократно.
Описанный мной в статье пример в первую очередь актуален для систем, которые пишут в файл только из одного процесса, например, Desktop applications.