Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 21
Нужен ответ определенного вида, с определенным типом. От xml'я до plain/text.
Раньше это реализовывалось на всроенном perl — с этим патчем, много проще.
Раньше это реализовывалось на всроенном perl — с этим патчем, много проще.
Кстати, а с чего вы взяли что только пустой xml?
простой вопрос — зачем всё это?
хотя бы одно разумное применение можно?
хотя бы одно разумное применение можно?
1) self testing nginx, для этого примемения оно и было написано.
2) создание быстрого прототипа.
2) создание быстрого прототипа.
По stub_status_module не получается определить состояние nginx?
Извините, но как можно проверить через stub_status на этапе сборки nginx а не поломал ли я логику хождения к upstream?
Первая задача которую решает этот модуль это представление кусков логики для возможности тестирования nginx'а на этапе сборки. Идея по применению для прототипов появилась только на выходных. А вот сейчас, как оказалось, удобно использовать для всяких заглушек поживому.
Первая задача которую решает этот модуль это представление кусков логики для возможности тестирования nginx'а на этапе сборки. Идея по применению для прототипов появилась только на выходных. А вот сейчас, как оказалось, удобно использовать для всяких заглушек поживому.
Извините, но я не понимаю о какой сборке вы говорите, если можно поясните, пожалуйста, на примере.
Когда вы говорили «self testing nginx», я понял, что выхоитет проверить что nginx работает и отвечает на запросы.
Как при помощи вашего модуля можно проверить, что условия описывающие какой запрос надо проксировать и куда, работают?
Когда вы говорили «self testing nginx», я понял, что выхоитет проверить что nginx работает и отвечает на запросы.
Как при помощи вашего модуля можно проверить, что условия описывающие какой запрос надо проксировать и куда, работают?
Сборке nginx, из исходных кодов.
А проверить просто, у меня *свой* аналог upstream ;)
Можно считать что это кусок того кода, который я использую для тестирования функциональности от билда к блилду.
А проверить просто, у меня *свой* аналог upstream ;)
Можно считать что это кусок того кода, который я использую для тестирования функциональности от билда к блилду.
> который я использую
Вот поэтому и интересует вопрос — а нам он зачем?
Я может отстал от жизни, но неужели много людей, не являющиеся разработчиками nginx, собирают его из сырцов?
2) создание быстрого прототипа.
Быстрого прототипа чего?
Сайта? Так проще html-страницы накидать, чем править конфиг nginx.
или может прототипа модуля nginx?
Вот поэтому и интересует вопрос — а нам он зачем?
Я может отстал от жизни, но неужели много людей, не являющиеся разработчиками nginx, собирают его из сырцов?
2) создание быстрого прототипа.
Быстрого прототипа чего?
Сайта? Так проще html-страницы накидать, чем править конфиг nginx.
или может прототипа модуля nginx?
> Вот поэтому и интересует вопрос — а нам он зачем?
Лично вам? Я не знаю ваши задачи. Но несколько человек изъявило желание видеть этот модуль. Например тут: www.lexa.ru/nginx-ru/msg19784.html
> Я может отстал от жизни, но неужели много людей, не являющиеся разработчиками nginx, собирают его из сырцов?
Люди которые хотят от него несколько большего, чем есть в коробке от дистрибутива собирают его.
> Так проще html-страницы накидать, чем править конфиг nginx…
А вы попробуйте сделать post запрос в html страницу. Или для отладки ответа от backend (которого еще нет!). Nginx может выдавать по условиям коды ошибок, а вот разный текст и код 200 нет. Я решил исправить это.
Да, это open source, я просто написал этот модуль, потратив свое время. Я не заставляю лично вас пользоваться им. Если вы не видите в этом смысл, то он вам не нужен. Возможно, тут есть человек или два, которым этот модуль съэкономит время. Вот для них я это и постил тут.
Лично вам? Я не знаю ваши задачи. Но несколько человек изъявило желание видеть этот модуль. Например тут: www.lexa.ru/nginx-ru/msg19784.html
> Я может отстал от жизни, но неужели много людей, не являющиеся разработчиками nginx, собирают его из сырцов?
Люди которые хотят от него несколько большего, чем есть в коробке от дистрибутива собирают его.
> Так проще html-страницы накидать, чем править конфиг nginx…
А вы попробуйте сделать post запрос в html страницу. Или для отладки ответа от backend (которого еще нет!). Nginx может выдавать по условиям коды ошибок, а вот разный текст и код 200 нет. Я решил исправить это.
Да, это open source, я просто написал этот модуль, потратив свое время. Я не заставляю лично вас пользоваться им. Если вы не видите в этом смысл, то он вам не нужен. Возможно, тут есть человек или два, которым этот модуль съэкономит время. Вот для них я это и постил тут.
Извините, но как можно проверить через stub_status на этапе сборки nginx а не поломал ли я логику хождения к upstream?
Первая задача которую решает этот модуль это представление кусков логики для возможности тестирования nginx'а на этапе сборки. Идея по применению для прототипов появилась только на выходных. А вот сейчас, как оказалось, удобно использовать для всяких заглушек поживому.
Первая задача которую решает этот модуль это представление кусков логики для возможности тестирования nginx'а на этапе сборки. Идея по применению для прототипов появилась только на выходных. А вот сейчас, как оказалось, удобно использовать для всяких заглушек поживому.
BTW Другим будет проще получить ваш патч если он будет лежать в какой нить VCS. Git кстати идеально подходит. Вы можете выложить на github вашу патченную версию nginx.
И на каждый патч выкладывать отдельный репозиторий?
Возможно я когда-то соберусь с духом и выложу в публичный доступ git репозиторий, в котором веду разработку, в том числе, и этого патча.
И такие вещи, проще, правда, получать именно в виде patches, нежеле отдельно стоящего nginx-fork.
Да, я не хочу форкать, как минимум публично, nginx.
Возможно я когда-то соберусь с духом и выложу в публичный доступ git репозиторий, в котором веду разработку, в том числе, и этого патча.
И такие вещи, проще, правда, получать именно в виде patches, нежеле отдельно стоящего nginx-fork.
Да, я не хочу форкать, как минимум публично, nginx.
Извиняюсь за небольшой оффтоп по поводу git. Видимо стоит описать свои мысли о гит в отдельной статье на habr.
> И на каждый патч выкладывать отдельный репозиторий?
Обычно поступают след. спопобом: 1 репозиторий 2 бранча. первый бранч т. н. origin. Это vanilla версия от автора в данном случае от Игоря Сысоева. В этой ветке будет то что и у Игоря в офиц. репозитории. Во второй ветке (master) вы ведете свою разработку. Переодически вытягиваете изменения из репозирория Игоря в свой origin и затем мержите в master.
> Да, я не хочу форкать, как минимум публично, nginx.
Вас видимо пугает слово форк. Это действительно было плохо с cvs/svn по причине того что там очень сложно синхронизировать (мержить) удаленные репозитории.
С git форк превратился из гадкого утенка в лебедя. Теперь форк репозитория это идеологически верный способ разработки. Особенно «нестандартных» фич, которые возможно не сразу войдут в главный репозиторий, но при этом вам хочется расшарить свою работу для других.
Для того чтобы смержить чейто удаленный репозиторий достаточно набрать
git merge git://repote-host/repo.git
Вот к примеру проект rails имеет 347 публичных форков. github.com/rails/rails/network Ядро линукс — куда больше.
Да кстати рекомендую вот эту лекцию Линуса Торвальдса (автора git). Предупреждаю сразу — это возможно полностью перевернет ваше представление о version control systems. www.youtube.com/watch?v=4XpnKHJAok8
> И на каждый патч выкладывать отдельный репозиторий?
Обычно поступают след. спопобом: 1 репозиторий 2 бранча. первый бранч т. н. origin. Это vanilla версия от автора в данном случае от Игоря Сысоева. В этой ветке будет то что и у Игоря в офиц. репозитории. Во второй ветке (master) вы ведете свою разработку. Переодически вытягиваете изменения из репозирория Игоря в свой origin и затем мержите в master.
> Да, я не хочу форкать, как минимум публично, nginx.
Вас видимо пугает слово форк. Это действительно было плохо с cvs/svn по причине того что там очень сложно синхронизировать (мержить) удаленные репозитории.
С git форк превратился из гадкого утенка в лебедя. Теперь форк репозитория это идеологически верный способ разработки. Особенно «нестандартных» фич, которые возможно не сразу войдут в главный репозиторий, но при этом вам хочется расшарить свою работу для других.
Для того чтобы смержить чейто удаленный репозиторий достаточно набрать
git merge git://repote-host/repo.git
Вот к примеру проект rails имеет 347 публичных форков. github.com/rails/rails/network Ядро линукс — куда больше.
Да кстати рекомендую вот эту лекцию Линуса Торвальдса (автора git). Предупреждаю сразу — это возможно полностью перевернет ваше представление о version control systems. www.youtube.com/watch?v=4XpnKHJAok8
> Обычно поступают след. спопобом: 1 репозиторий 2 бранча. первый бранч т. н. origin. Это vanilla версия от автора в данном случае от Игоря Сысоева. В этой ветке будет то что и у Игоря в офиц. репозитории. Во второй ветке (master) вы ведете свою разработку. Переодически вытягиваете изменения из репозирория Игоря в свой origin и затем мержите в master.
У меня сейчас так и сделано. Именно есть upstream и есть сто-тыщ-мильенов веточек с разными патчами.
> Вас видимо пугает слово форк. Это действительно было плохо с cvs/svn по причине того что там очень сложно синхронизировать (мержить) удаленные репозитории.
Нет, меня не пугает слово форк. Меня пугают трудозатраты на поддержку форка. Форкнуть nginx просто. Но его тогда надо и поддерживать. Сейчас я выпускаю достаточно автономные патчи. И перед каждым публичным патчем я думаю, а стоит ли выкладывать и сколько этот патч съест времени после релиза нового nginx.
> Да кстати рекомендую вот эту лекцию Линуса Торвальдса (автора git). Предупреждаю сразу — это возможно полностью перевернет ваше представление о version control systems. www.youtube.com/watch?v=4XpnKHJAok8
Спасибо. Но я немного «маньяк» в областе scm. Т. е. я с блеском в глазах смотрю на все новые системы ;)
У меня сейчас так и сделано. Именно есть upstream и есть сто-тыщ-мильенов веточек с разными патчами.
> Вас видимо пугает слово форк. Это действительно было плохо с cvs/svn по причине того что там очень сложно синхронизировать (мержить) удаленные репозитории.
Нет, меня не пугает слово форк. Меня пугают трудозатраты на поддержку форка. Форкнуть nginx просто. Но его тогда надо и поддерживать. Сейчас я выпускаю достаточно автономные патчи. И перед каждым публичным патчем я думаю, а стоит ли выкладывать и сколько этот патч съест времени после релиза нового nginx.
> Да кстати рекомендую вот эту лекцию Линуса Торвальдса (автора git). Предупреждаю сразу — это возможно полностью перевернет ваше представление о version control systems. www.youtube.com/watch?v=4XpnKHJAok8
Спасибо. Но я немного «маньяк» в областе scm. Т. е. я с блеском в глазах смотрю на все новые системы ;)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
патч для «простого ответа»