Особливості HTTP запитів в ZennoPoster

Не рідко коли читаєш форум можна побачити теми, де потенційні клієнти хочуть автоматизувати роботу з сайтом. І коли починаєш спілкуватись, виявляється, що однією із основних вимог є використання HTTP запитів і не викоростання браузера. Такий попит звичайно накладає певні вимоги до знаннь виконавця. З цим потрібно розібратись один раз!

Специфіка роботи з ZennoPoster у тому, що з його допомогою можна виконувати запити з будь-якими заголовками і даними, при чому ігноруючи будь-які специфікації (наприклад браузер не дозволяє відправляти запити автоматично з одного домена на інший аргументуючи це CORS, не дозволяє одержати доступ деяких типів cookie, не дозволяє поміняти заголовок Origin, слідує правилам кешування запитів, кешування DNS з’єднаннь, і навіть виконує вимоги щодо ідемпотентності запитів). Так, я розумію, що мабуть я перечислив терміни, які могли не зустрічатись раніше – проте я хотів показати що відмінностей між будь-яким іншим клієнтом і програмою ZennoPoster суттєві.

І от, в якийсь момент часу ми одержуємо замовлення на виконання роботи. Починаємо формувати і відправляти запити – а сервер до якого ми звертаємось не приймає їх. І це логічна поведінка, тому що може бути, що згідно специфікації цей запит повинен був бути закешованим, або цей домен не приймає запити згідно CORS чи ще по якійсь іншій причині. Ми сидимо, ломаємо голову, черговий раз знаходимо тему на форумі про те, що ZennoPoster не вміє відправляти запити за допомогою http/2 і нам приходить геніальна думка про те що це саме наш випадок, і що треба вирішувати саме цю проблему.

Так от, я хочу застерегти від таких думок – в першу чергу, потрібно розуміти що саме хоче получити сервер і за допомогою якого HTTP методу. Досить часто буває, що відправляючи запит POST з тілом json самі дані формуються у вигляді текстового рядка, де між подвійними кавичками вставляється макрос зі змінною. І на дані всередині ми ніяк не впливаємо – а значить якщо там попадеться подвійна кавичка – це спортить наші дані, так як вона не буде екранованою.

Ще проблема може бути тоді, коли не добавляється заголовок Origin який потрібен, щоб пройти CORS, а зі своєї сторони ми не розуміємо, чому сайт не приймає запит.

Буває також, що перш ніж відправити запит POST чи GET потрібно спочатку відправити OPTIONS, щоб дати зрозуміти серверу що потрібно підготувати дані (а у відповіді можуть находитись ті заголовки, і ті HTTP методи, які можна відправити в найближчий час). І після такого OPTIONS може бути прийдеться почекати декілька секунд, щоб дати час серверу підготувати відповіть на майбутній запит.

Доречі ZennoPoster дійсно не вміє відправляти запити через http/2 з’єднання, тому користувачами для таких цілей використовуються альтернативні рішення – або свої консольні програми, яким ZennoPoster дає команди відправити запит, або стандартний cURL, який також визивається у вигляді командного рядка CMD. Проте, ця проблема зустрічається рідко – зазвичай помилки при спробах відправити запит і одержати відповідь саме в заголовках сформованого запиту (або забагато заголовків, або замало, потрібно підбирати)

Останнім часом бачу, що розробники переглядають саме консоль розробника в браузері Chrome, щоб знайти потрібні запити і дані. Потім збирають щось подібне у ZennoPoster і дивуються, що у них нічого не працює. Проблема в тому, що у деяких випадках Chrome може змінювати результат, який відображається, а також змінювати дані, які відправляються. Саме тому вже багато років всі рекомендують використовувати аналізатори трафіка, якими користуються QA тестувальники, наприклад Fiddler. Не потрібно нехтувати цією рекомендацією тільки тому, що мова інтерфейсу там англійська. Уже через декілька днів перегляду трафіка привикаєш, знаєш що куди клікати, і від англійської майже не залишається дискомфорту.

Згадав ще одну проблему, яка пов’язана з кількістю з’єднаннь – саме через цю проблему замовникам приходиться купляти проксі з дуже великим запасом потоків. Так от, потрібно розуміти, що заголовок Connection: close заставляє розірвати з’єднання, тим самим економить кількість потоків. Якщо в запитах буде заголовок Connection: keep-alive – то з’єднання розриватись не буде – а вже при наступному запиті всерівно відкриється нове з’єднання. Тому, в залежності від того якої поведінки хочеться досягнути – потрібно використовувати цей заголовок. Інакше, наприклад при роботі з Bing не получиться уникнути 429 помилки (там потрібно щоб з’єднання не розривалось), а при роботі з деякими проксі провайдерами – без розриву з’єднання прийдеться платити набагато дорожче.

В будь-якому випадку, рекомендую пошукати в вікіпедії і на youtube всі незрозумілі слова, щоб тим самим краще розібратись з темою HTTP методів відправки запитів. Навіть якщо подивитись декілька відео про REST API і CRUD на PHP буде набагато простіше вирішувати завдання замовників, адже ця інформація допоможе зрозуміти що саме відбувається на стороні сервера при відправці того чи іншого запиту.