Здравствуйте, acDev, Вы писали:
D>Здравствуйте, Handie, Вы писали:
H>>Вот, предложили сделать забавное заданице H>>Душевные ребята
D>Ребята из рэмблера?
Здравствуйте, ML380, Вы писали:
V>>select и "большое количество одновременных запросов" "под Linux" — так себе идея. ML>А как можно по-другому?
epoll, kqueue.
AG>Судя по их ограничению 3 дня на выполнение- нормальное задание, действительно почитать API и написать, 8-15часов чистого времени на почитать, подумать, написать, отладить.
H>>Сам про три дня придумал?
AG>Зачем же- ссылка на блог того нанимателя пробегала здесь в теме. С интересом почитал.
Ссылка совсем не туда. И контора эта — не Рамблер.
лет пять назад я уже написал HTTP сервер в качестве тестового — с тех пор зарекся иметь дело с неадекватными работодателями и делать тестовые задания
Здравствуйте, Handie, Вы писали:
H>Вот, предложили сделать забавное заданице
H>Разработать простейший WEB server, отвечающий следующим требованиям: H>1) Возвращает статический HTML контент (CGI не нужны). H>2) Однопроцессный, но многопоточный. H>3) Рассчитан на большое количество одновременных запросов. H>4) Корректно возвращает HTTP коды ошибок и заголовки. H>5) Никаких стронних библиотек — только STL, posix, glibc H>6) Сервер должен компилироваться и запускаться под Linux. "
H>Душевные ребята
Здравствуйте, okman, Вы писали:
H>>5) Никаких стронних библиотек — только STL, posix, glibc
O>М-да... Нет, я все понимаю, но без сторонних либ это ж сколько кода лишнего писать ! O>Уже просто для обработки входящего GET-запроса нужна целая HTTP state machine, O>которая парсит статусную строку, вытаскивает URL, заголовки и т.д. O>Только это пока напишешь да протестируешь, уже уйдет прилично времени, боюсь даже O>предположить, сколько именно.
Зачем его парсить? Надо пропарсить первую строку вида GET {url} HTTP/1.0, всё остальное парсить не надо, прочитать файл, соответствующий url-у и выплюнуть его клиенту. Если файла нет, выплюнуть 404. Если первая строка не подохдит под указанный шаблон, bad request сказать.
Здравствуйте, vsb, Вы писали:
vsb>Зачем его парсить? Надо пропарсить первую строку вида GET {url} HTTP/1.0, всё остальное парсить не надо, прочитать файл, соответствующий url-у и выплюнуть его клиенту. Если файла нет, выплюнуть 404. Если первая строка не подохдит под указанный шаблон, bad request сказать.
Про заголовки в запросе не забыли ? Если их проигнорировать, реализация HTTP-сервера
будет некорректной. Например, клиент хочет принимать только HTML в кодировке UTF-8, для
чего указывает заголовки "Accept: text/html, *;q=0" и "Accept-Charset: UTF-8, *;q=0", а
в файле у нас лежит text/plain в Windows-1251. По теории HTTP, здесь нужно вернуть
статус "406 Not Acceptable". Понятно, что задание тестовое и на такие "мелочи" вроде
как могут и глаза закрыть, но ведь топикстартер писал, что (цитата):
4) [сервер] корректно возвращает HTTP коды ошибок и заголовки.
Здравствуйте, kaa.python, Вы писали:
KP>Только что понял, что ты не сказал самого главного. А сколько денег-то дают?
Автор не рассказал ещё и того, что в этой компании (не помню название) предлагают ещё и другое задание в качестве альтернативы — не такое масштабное, какой-то С++ контейнер. Или вообще какой-то собственный С++-код с многопоточностью.
Здравствуйте, Handie, Вы писали:
H>Вот, предложили сделать забавное заданице
H>Разработать простейший WEB server, отвечающий следующим требованиям: H>1) Возвращает статический HTML контент (CGI не нужны). H>2) Однопроцессный, но многопоточный. H>3) Рассчитан на большое количество одновременных запросов. H>4) Корректно возвращает HTTP коды ошибок и заголовки. H>5) Никаких стронних библиотек — только STL, posix, glibc H>6) Сервер должен компилироваться и запускаться под Linux. "
H>Душевные ребята
Сколько-то лет назад я делал именно такое тестовое задание. Задание получил в среду-четверг. Приступил в субботу утром, с перерывами потратил все выходные. Оффер получил, но так им и не воспользовался.
Здравствуйте, okman, Вы писали:
vsb>>Зачем его парсить? Надо пропарсить первую строку вида GET {url} HTTP/1.0, всё остальное парсить не надо, прочитать файл, соответствующий url-у и выплюнуть его клиенту. Если файла нет, выплюнуть 404. Если первая строка не подохдит под указанный шаблон, bad request сказать.
O>Про заголовки в запросе не забыли ? Если их проигнорировать, реализация HTTP-сервера O>будет некорректной. Например, клиент хочет принимать только HTML в кодировке UTF-8, для O>чего указывает заголовки "Accept: text/html, *;q=0" и "Accept-Charset: UTF-8, *;q=0", а O>в файле у нас лежит text/plain в Windows-1251. По теории HTTP, здесь нужно вернуть O>статус "406 Not Acceptable". Понятно, что задание тестовое и на такие "мелочи" вроде O>как могут и глаза закрыть, но ведь топикстартер писал, что (цитата): O>
O>4) [сервер] корректно возвращает HTTP коды ошибок и заголовки.
Имхо, без конкретной спецификации подобных ситуаций самому, конечно, можно и apache http server в итоге написать, но это явно не то, что хотят видеть от тестового задания. В тестовой задаче хотят видеть, как человек организует код, как пишет комментарии, обработку ошибок. В данном задании базовые навыки работы со строками, файлами, понимание принципов написания серверов, держащих большое число соединений. А как вы пишете — там придётся конфиг писать, чтобы задавать кодировку файлов (ведь каждый файл может быть в своей кодировке). Для конфига парсер А на практике браузеру по барабану, он любую кодировку покажет, ещё и сам определит, если неправильно будет указано.
И вообще
If an Accept header field is present,
and if the server cannot send a response which is acceptable
according to the combined Accept field value, then the server SHOULD
send a 406 (not acceptable) response.
А SHOULD это не MUST.
Ну а так — парсинг заголовков не намного сложнее. Читаем каждую строку, находим ':', что получилось складываем в отображение name->value, останавливаемся на первой пустой строке. Потом по этому отображению при необходимости проверяем наличие интересующего заголовка и смотрим, чего от нас хотят.
A>Автор не рассказал ещё и того, что в этой компании (не помню название) предлагают ещё и другое задание в качестве альтернативы — не такое масштабное, какой-то С++ контейнер. Или вообще какой-то собственный С++-код с многопоточностью.
Ну да, пришлите код который писали на прошлой или позапрошлой работе. Я на такие предложения всегда отвечал — NDA.
Я принципиально не делаю тестовые задания, просто в этот раз меня поразила масштабность задания
Здравствуйте, vsb, Вы писали:
vsb>Имхо, без конкретной спецификации подобных ситуаций самому, конечно, можно и apache http server в итоге написать, но это явно не то, что хотят видеть от тестового задания. В тестовой задаче хотят видеть, как человек организует код, как пишет комментарии, обработку ошибок. В данном задании базовые навыки работы со строками, файлами, понимание принципов написания серверов, держащих большое число соединений.
В том-то и дело, что из данных входных условий, которые приведены в тестовом задании,
совершенно непонятно, что именно будут проверять и что хотят видеть в итоге.
Возможно, это как раз тест на глубокое понимание TCP и HTTP. Может быть, сделанный
экзаменуемым сервер сразу же запустят в тестовой среде и начнут бомбить его искусно
подготовленными заранее HTTP-запросами с "изюминками", чтобы сразу отсеять слишком
наивные или некорректные реализации. Или натравят на сервер какой-нибудь peach и
будут решать в таком духе: "продержался его сервак более часа — берем на работу".
При таком раскладе, кстати, сразу становится понятно, почему нельзя использовать
сторонние реализации, такие как apache или nginx, так как они выдержат подобные
испытание, а наспех писанный за пару вечеров сервер — вряд ли.
vsb>А как вы пишете — там придётся конфиг писать, чтобы задавать кодировку файлов (ведь каждый файл может быть в своей кодировке). Для конфига парсер А на практике браузеру по барабану, он любую кодировку покажет, ещё и сам определит, если неправильно будет указано.
Браузерам-то по барабану, а для каких-то приложений поддерживать тучу кодировок, способов
сжатия и динамически определять тип контента — слишком обременительно. Неизвестно же, из браузера
там будут тестировать этот сервер или нет.
vsb>И вообще
vsb> If an Accept header field is present, vsb> and if the server cannot send a response which is acceptable vsb> according to the combined Accept field value, then the server SHOULD vsb> send a 406 (not acceptable) response.
vsb>А SHOULD это не MUST.
Можно забить на SHOULD, но это будет "conditionally compliant".
vsb>Ну а так — парсинг заголовков не намного сложнее. Читаем каждую строку, находим ':', что получилось складываем в отображение name->value, останавливаемся на первой пустой строке. Потом по этому отображению при необходимости проверяем наличие интересующего заголовка и смотрим, чего от нас хотят.
В целом, я с Вами согласен — ради тестового задания вряд ли стоит порождать такого
монстра, который бы выдерживал большие нагрузки, умело обрабатывал некорректные
запросы, работал через прокси, имел кэш и т.д. Но согласитесь, даже в таком простом
деле, как парсинг заголовков, даже для тестового задания придется учесть некоторые
моменты, иначе решение никакой критики не выдержит и свалится на первой же встряске.
Например, пришло два одинаковых заголовка с разными значениями, или где-то потерялись
закрывающие кавычки, или в запросе встретился заголовок Trailer, который нужно не
потерять после вычитки body, и т.д. Если речь идет про устройство в такую контору,
как Рамблер или Гугл, то все, что связано с работой сетей и, в частности, обработкой
HTTP, может принести дополнительные баллы.
Здравствуйте, kaa.python, Вы писали:
Pzz>>Ну вроде речь о том, что надо с 793-го начинать, не шла
KP>А как ты реализуешь требования 1 и 3 хотя бы не проглядев RFC относящиеся в HTTP?
Ну я в нем свободно ориентируюсь, вообще-то. Это дает мне право утверждать в резюме, что я знаю протокол HTTP
Но в принципе, я не стал бы давать соискателю задачу, которая требует больше 1-2 часов на решение. Ну или если неймется, такая работа должна быть оплачена.
