Если есть методика и все её придерживаются, то обсуждение возможно. Если методики нет, то любое обсуждение превращается в балаган. Такая демократия ничего хорошего не сулит

Пайчарм я купил, так что тоже просто поделюсь (хотя CLion не прочь поиметь на год):

Интегрировались мы недавно с кастомной реализацией S3 поверх Ceph кластера, закрытого проксёй с шифрованием контента. В этой проксе была написана своя валиадация pre-signed URL-ов.
На нашей стороне был сервер на aiohttp, который слал запросы в эту S3, и почему-то запросы не проходили проверку сигнатуры, хотя с Амазон S3 всё было отлично. И через curl или requests было всё ОК.
Начал изучать в чём же разница, юзал разные сервисы типа requestbin.com и простой nc, посылая в них запросы по разному: через curl или через aiohttp.
Случайно обратил внимание, что aiohttp в query string слеши кодирует "процентиками", хотя в эталонном запросе они были не экранированы (по стандарту их можно не экранировать в query string).  Оказалось, что:
- во первых aiohttp по дефолту "перекодирует" все URL-ы на которые посылает запросы, экранирует в них всё что надо (и не очень надо). Что бы он этого не делал, надо ему URL передавать не строкой, а в виде объекта yarl.URL(), который создавать с отключением "перекодирования".
- во вторых набор символов допустимых для query string немного отличается от набора допустимого для canonical string, из которой считается подпись (она тоже кодируется с помощью url_encoding-а)
- в третьих, в шифрующей проксе нашего клиента была не очень корректно сделана проверка подписи. Они просто брали query string как она есть, и считали от неё сигнатуру. В результате они её считали от закодированых слешей, а наш сервис считал от нормальных слешей. Амазон делает это более правильно - он сначала декодирует query string, а потом строит canonical string c кодированием по своим правилам - поэтому с ним у нас не было проблем.

Вывод: разрабатывая http-сервисы никогда не полагайтесь на "правильное" кодирование query string, т.к. есть несколько вариантов сделать это правильно. Всегда декодируйте его и потом кодируйте по своему, если это имеет значение.

И вот по поводу всяких сервисов типа requestbin.com - я несколько штук разных посмотрел, и все они не идеальные. Мало кто из них показывает "сырой" запрос в том виде как он пришёл. Все они его декодируют и по пути добавляют своего хлама. Например nginx (или что там у них на "фронте") добавляет какие-то служебные заголовки типа x-forwarded-for.
А вот nc - это то что нужно.

из того что помню, пару раз убил кучу времени на магию, связанную со случайно запятой в конце строки.. Ну это боян так то

Самая боль это изменения в типах при переходе с 2.7.+ на 3.6+

Главное все живы-здоровы)

В контексте того, что мы тестируем это звучит страшно :-)

Дятлы разрушают построенную компьютерщиками цивилизацию, как и было предсказано.

В США бушует эпидемия кибершантажа, которой безуспешно противостоят ФБР, Министерство внутренней безопасности и Секретная служба.

http://amp.gs/OUig

Всего от подобных атак за последние два года пострадали свыше полусотни городов США — как маленьких, так и крупных.

#whois
привет всем!) Занимаюсь тестированием, активно изучаю python)

Привет, коллега!

Это будущее.

кстати тут пичарм с 30% скидкой дают https://www.jetbrains.com/pycharm/promo/support-python/

похоже он на продление не работает.. только для новых 😞

а у нас все сами себе покупают, а не ДЮ?

да. но одно время возвращал

по-моему мы столкнулись с настоящими ботами, а не ИО

Я даже не знаю. Я в замешательстве.

давно бы уже велкомбота написал