Рабочее

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

Я не помню, рассказывал ли я тут о моём отношении к своим работам. Поэтому позволю себе высказаться. Я не занимаюсь чем-то художественно интересным, как например, камрад __mixa__, который имеет возможность фотографировать самолётики и тому подобное. Я работаю в сфере услуг, причём глубоко айтинизированной её части. Айтинизированной — от IT. Там нужны программисты в довольно массовом порядке, и одним из таких программистов я и являюсь. Мне нравиться, что я делаю, но мне отнюдь не интересно расписывать все перипетии своего рабочего места. Поэтому информацию об этом в публичных каналах я свожу к минимуму. В личной переписке могу немного пораспространятся, если тема зайдет об этом.

Итак, был написан новый шлюз — на питоне. Не то, чтобы совсем каркас, но и не законченный шлюз. Протокол работал, но нужно было реализовать дополнительные опции, так как разные клиенты имеют разные заморочки. В общении использовалось обычный POST-запрос.

И вот попались мне одни ребята — очень крупный клиент, по этой причине послать их просто нафиг не мог. Иногда бывало ребята на той стороне тупили по жёсткой, вплоть до того, что приходилось поднимать менеджеров и вставлять им люлей через их директора. Но тут ребята серьёзные, крупные — по идее у них всё должно быть круто. Поэтому я, на всякий случай, всё проверял. В итоге, ошибка оказалась и на моей стороне, но настройка их сервера — отвал башки

Проблема с ними была в том, что из POST-запроса не читался самый главный параметр — ID запроса. Сначала мне высказали причину, что в начале параметра пробелы. Проверка на Apache и самодельном твистедовом сервере показала, что все параметры приходят корректно и без пробелов. Заверив их, что у меня при тестах всё корректно — я получил новое предположение: что это просто в логах так отображается, а на самом деле это не пробелы, а перенос строки. «О-о-к», — подумал я. Откуда взяться переносу строки? Немного подумав, я решил не парсить POST-запрос от шлюза PHP-шечкой в Apache или средствами твистеда, а просто сдампить то, как он приходит в сыром виде.

И я нашел проблему! Последним заголовком всегда шел Authorization. А Authorization у нас какой? Правильно — Basic. Basic Authorization — это просто пара «логин:пароль», закодированная в base64. В питоне достаточно воспользоваться стандартным методом encode у строки для такого преобразования. Но! В отличии от встроенного же модуля — этот метод всегда добавляет LF в конце. С одной стороны, это корректно, в base64 LF может быть хоть через каждый символ — функция декода должна их всех отбросить и декодировать только «текст». Но с другой стороны, в HTTP-заголовках такого всё-таки быть не должно. И я бы понял, если бы их сервер дал мне отлуп с неправильным логином/паролем. Но! Эти ребята умудрились этот LF перенести из заголовков в тело POST-запроса! То есть через два разделителя, а по факту — четыре символа (CRLF отделяющий один заголовок от другого, плюс CRLF отделяющий заголовок от тела)!

КАК?! FUKKEN MAGIC! Ну итог прост: баг поправлен, все счастливы. Но мне всё-таки интересно: как так шизоидально нужно настроить сервер? =)

Похожие статьи