Comments 11
-зачем программист пишет гофер сервер?
-потому, что может, люди бы тоже, если б могли, эх… (с) анекдот про кота
-потому, что может, люди бы тоже, если б могли, эх… (с) анекдот про кота
Я думал вы его на Go напишете :(
да что вы, я серверный enterprise программист, пишу в основном на Джаве дремучих версий. JS-то умею едва-едва, а про Go и вовсе только краем уха слышал. слишком уж новая это штука для энтерпрайза. bolk вот сможет на нём написать, если захочет, конечно :)
Уже 3 года как написано, причём не в единственном экземпляре:
code.google.com/p/gogopherd/
github.com/nf/gogopherd/
Примечательно, что количество строк практически совпадает — примерно 140 в обоих реализациях.
code.google.com/p/gogopherd/
github.com/nf/gogopherd/
Примечательно, что количество строк практически совпадает — примерно 140 в обоих реализациях.
github.com/mischief/godwulf — ещё один пример. нормальная обработка ошибок делает его чуть-чуть длиннее.
кстати, тот вариант, который лежит на гуглокоде, написал Брэд Фитцпатрик, оригинальный автор ЖЖ.
кстати, тот вариант, который лежит на гуглокоде, написал Брэд Фитцпатрик, оригинальный автор ЖЖ.
Конечно, для домашних проектов, написанных от скуки, это не принципиально, но всё же не могу удержаться от замечаний по коду:
1. Нет проверки размера запроса. Вредный клиент может положить сервер, послав ему очень длинную последовательность единичек.
2. Если пакеты придут таким образом, что CR будет в одном пакете, а LF в другом, то клиент так никогда ответа и не получит.
3. Вероятно, query += порождает кучу копирований и реаллокаций, т.к. строки в JS (как и в Java) неизменяемы.
4. Не уверен, но вполне вероятно, клиент, добавляя в запрос точки, может получить доступ ко всей файловой системе.
1. Нет проверки размера запроса. Вредный клиент может положить сервер, послав ему очень длинную последовательность единичек.
2. Если пакеты придут таким образом, что CR будет в одном пакете, а LF в другом, то клиент так никогда ответа и не получит.
3. Вероятно, query += порождает кучу копирований и реаллокаций, т.к. строки в JS (как и в Java) неизменяемы.
4. Не уверен, но вполне вероятно, клиент, добавляя в запрос точки, может получить доступ ко всей файловой системе.
3. Строки неизменяемы в JS, да, и когда-то имело смысл вместо += использовать Array#join или даже String#concat, но сейчас считается что транслятор достаточно умен и такие вещи оптимизирует получше человека. Синтетические тесты это, в общем, доказывают, особенно для V8.
Полностью согласен.
Учитывая, что по спецификации селектор не может быть длиннее 255 символов (при этом поле отображаемого имени — не более 70; по задумке он обязан всегда влазить в один пакет), то если бы код предназначался для реального использования, на входе было бы необходимо поставить такую проверку. Это сразу сняло бы первые два замечания.
Четвёртое на самом деле полностью нивелируется другим багом, который не позволит выйти за пределы ROOT_DIR :)
Для третьего у меня нет оправдания, там однозначно надо использовать Buffer.toString(), а для answer += — Array.join(), или задействовать какой-нибудь StringBuilder.
Хорошо, что никто никогда не будет ставить этот экзерсис на пром.
Учитывая, что по спецификации селектор не может быть длиннее 255 символов (при этом поле отображаемого имени — не более 70; по задумке он обязан всегда влазить в один пакет), то если бы код предназначался для реального использования, на входе было бы необходимо поставить такую проверку. Это сразу сняло бы первые два замечания.
Четвёртое на самом деле полностью нивелируется другим багом, который не позволит выйти за пределы ROOT_DIR :)
Для третьего у меня нет оправдания, там однозначно надо использовать Buffer.toString(), а для answer += — Array.join(), или задействовать какой-нибудь StringBuilder.
Хорошо, что никто никогда не будет ставить этот экзерсис на пром.
А как же реализация в 30 строк? Или в 140 символов? Оно как то покошернее будет.
Sign up to leave a comment.
Когда программисту нечем заняться, он пишет Gopher-сервер