Виправлення проблем з кодуванням та декодуванням URL: Уроки з реальних веб-додатків - javascript.org.ua

У веб-розробці обробка URL є основним завданням. Незалежно від того, передаєте ви дані між фронтендом і бекендом або працюєте з API сторонніх розробників, розуміння кодування та декодування URL може врятувати вас від багатьох неприємних помилок. У цій статті ми розглянемо основні концепції обробки URL, практичні приклади та ключові уроки з реального досвіду, які я отримав під час розробки застосунку.

Відмова від відповідальності:
Ця відмова від відповідальності з’являється в кількох блогах. Хоча ChatGPT є потужним інструментом, його відповіді можуть не вистачати глибини, точності або обґрунтування через відсутність контексту, неправильне запитання або спроби AI дати відповіді, де їх не існує. Він не перевіряє факти та може пропустити ключові деталі. Ці блоги заповнюють ці прогалини, надаючи ясність там, де AI не справляється, і економлячи читачам цінний час.

Моя подорож з помилками кодування URL у GKE журналах

Під час аналізу журналів GKE в одному з моїх недавніх проєктів я зіткнувся з проблемою, коли бекенд час від часу повертав помилки для конкретних запитів до ендпоінту попереднього перегляду зображень. Журнали показували неправильно сформовані URL, що призводило до відмови бекенду обробляти ці запити.

Приклад журналу GKE

Ось загальний приклад помилки, яку було зафіксовано в журналах:

GET /image_preview?width=150&height=150&image_url=https%3A//example-bucket.s3.amazonaws.com/image.png HTTP/1.1  
500 Internal Server Error

Проблема полягала в параметрі запиту image_url, який виглядав неправильно сформованим. Зокрема, URL починався з https:/, а не https://. Ця проблема з кодуванням спричинила відмову бекенду обробляти запити. Після розслідування корінь проблеми був знайдений у тому, як URL кодувався та об'єднувався в шаблонах фронтенду, а потім декодувався на бекенді.

Ось розбір проблеми та рішення.

Проблема

Фронтенд використовував шаблони Jinja для створення URL, що містив URL зображення як параметр запиту. Шаблон Jinja використовував фільтри safe та urlencode наступним чином:

{% set encoded_url = example_image_url | urlencode %}  
{% set thumbnail_url = "https://example.com/image_preview?width=150&height=150&image_url=" | safe + encoded_url %}

Теоретично це мало б створити правильний URL. Однак журнали бекенду показали запити на кшталт:

https:/example.com/image_preview?width=150&height=150&image_url=https%3A//storage.googleapis.com/sample.png

Зверніть увагу на неправильний URL — https:/ замість https://. Це призвело до того, що бекенд відмовився обробляти запит.

Корінь проблеми

Фільтр urlencode правильно кодував image_url, але фільтр safe не очищав і не перевіряв об’єднаний рядок.
2.
Конкатенація базового URL (safe) та закодованого URL (urlencode) призвела до неповного URL з єдиним / після https:, що викликало відмову бекенду обробляти запит.

Виправлення

Щоб вирішити цю проблему, я замінив логіку конкатенації на безпечніший підхід, який кодував увесь рядок запиту, замість того, щоб вручну обробляти окремі параметри.

Оновлений приклад шаблону Jinja:

{% set query_params = {'width': 150, 'height': 150, 'image_url': example_image_url} %}  
{% set thumbnail_url = "https://example.com/image_preview?" + query_params | urlencode %}

Оновлений приклад коду для логіки попереднього перегляду зображень:

from urllib.parse import unquote  
from flask import Flask, request, send_file  
from PIL import Image  
from io import BytesIO  
import requests  

app = Flask(__name__)  

@app.route('/image_preview')  
def image_preview():  
 # Витягуємо та декодуємо параметри запиту  
 try:  
 encoded_image_url = request.args.get('image_url')  
 if not encoded_image_url:  
 return "Missing image_url", 400  

 image_url = unquote(encoded_image_url)  
 if not image_url.startswith("http"):  
 return "Invalid URL format", 400  

 width = int(request.args.get('width', 100))  
 height = int(request.args.get('height', 100))  
 if width > 1024 or height > 1024:  
 return "Dimensions too large", 403  

 except ValueError as ve:  
 return f"Invalid parameter: {str(ve)}", 400  

 except Exception as e:  
 return f"Error in parameter extraction: {str(e)}", 500  

 # Завантажуємо та обробляємо зображення  
 try:  
 response = requests.get(image_url, timeout=5)  
 response.raise_for_status()  

 image = Image.open(BytesIO(response.content))  
 image.thumbnail((width, height))  

 img_io = BytesIO()  
 image.save(img_io, format=image.format)  
 img_io.seek(0)  

 return send_file(img_io, mimetype=f'image/{image.format.lower()}')  

 except requests.exceptions.RequestException as re:  
 return f"Error fetching image: {str(re)}", 404  

 except IOError as io:  
 return f"Error processing image: {str(io)}", 500  

 except Exception as e:  
 return f"Unexpected error: {str(e)}", 500  

if __name__ == "__main__":  
 app.run(debug=True)

Цей підхід гарантує:

Весь рядок запиту безпечно кодується на фронтенді.
Бекенд декодує та перевіряє всі параметри запиту перед обробкою зображення.

Погляди на кодування та декодування

Чому кодувати на фронтенді?

Кодування на фронтенді гарантує, що спеціальні або небезпечні символи в параметрах запиту будуть безпечно передаватися в URL. Символи, такі як :, /, ? і пробіли, можуть порушити структуру URL, якщо їх не закодувати. Це важливо при передачі даних, згенерованих користувачем або з зовнішніх джерел, оскільки:

Зберігається цілісність даних: Спеціальні символи перетворюються в стандартизований формат (наприклад, : стає %3A, / стає %2F).
Покращується безпека: Перешкоджає потенційному впровадженню запитів або неправильному тлумаченню URL.
Гарантується відповідність стандартам HTTP: Закодовані URL відповідають стандартам HTTP, уникнувши помилок при розборі в проміжних системах або бекенді.

Чому декодувати на бекенді?

Декодування на бекенді необхідне для відновлення оригінального image_url для обробки. Хоча закодовані URL безпечні для передачі, вони не можуть бути використані в закодованому вигляді (наприклад, https%3A%2F%2Fexample.com). Декодування повертає URL до його оригінального формату для таких завдань, як завантаження ресурсів або подальша перевірка.

Чи відбувається подвійне кодування?

Перш ніж зануритися в подвійне кодування, давайте уточнимо, що це означає. Подвійне кодування відбувається, коли дані кодуються кілька разів без необхідності, часто призводячи до проблем, коли спеціальні символи перевищують свою норму кодування. Однак у нашому випадку процес є навмисним і не є справжнім подвійним кодуванням. Це, швидше, двоетапний процес:

Кодування на фронтенді: Перетворює небезпечні символи в безпечний для URL формат для передачі.
2.
Декодування на бекенді: Відновлює оригінальні дані для обробки.

Цей підхід забезпечує надійний і безпечний потік даних між фронтендом і бекендом.

Додатковий контент: Чому операції Pillow є необхідними для попереднього перегляду зображень?

Бібліотека Pillow відіграє важливу роль у функціональності попереднього перегляду зображень.

Цей розділ є додатковим і не безпосередньо пов'язаний з кодуванням та декодуванням URL, але він включений для читачів, які хочуть зрозуміти, як обробка зображень доповнює загальну функціональність.

Ось чому це незамінно:

1. Динамічне зміщення розміру зображень

При обробці зображень, наданих користувачем або отриманих з зовнішніх джерел, часто необхідно змінювати розміри для оптимізації продуктивності та поліпшення користувацького досвіду. Метод thumbnail() з Pillow ефективно змінює розмір зображення, зберігаючи співвідношення сторін. Це особливо важливо для:

Зменшення використання пропускної здатності при подачі менших зображень.
Забезпечення однакового відображення на різних пристроях.

2. Сумісність форматів

Зображення з зовнішніх джерел можуть бути різних форматів (наприклад, JPEG, PNG, GIF). Pillow забезпечує правильну обробку цих форматів та їх можливість перетворення, якщо це необхідно, що робить додаток більш універсальним.

3. Обробка в пам'яті

Використання BytesIO дозволяє додатку обробляти і повертати зображення без їх запису на диск, що призводить до:

Швидшої продуктивності.
Зниження вимог до зберігання.

4. Обробка помилок для пошкоджених або недійсних зображень

Pillow надає надійні методи для виявлення та обробки недійсних файлів зображень, що гарантує, що додаток не зламається при зустрічі з пошкодженими даними.

Чому Pillow необхідна тут?

Точка попереднього перегляду зображень динамічно отримує, обробляє та подає зображення відповідно до розмірів, заданих користувачем. Без Pillow:

Додаток не матиме надійного способу змінювати розміри зображень динамічно.
Обробка різних форматів зображень або неправильних файлів була б значно складнішою.

Інтеграція Pillow робить точку попереднього перегляду потужним і гнучким інструментом для динамічної обробки зображень, забезпечуючи найкращу продуктивність і користувацький досвід.

Основні уроки

Завжди правильно кодуйте рядки запиту Використання бібліотек або вбудованих утиліт для кодування рядків запиту гарантує, що URL будуть безпечними для передачі.
Декодуйте URL перед обробкою Бекенд повинен декодувати кодування URL, щоб точно відновити оригінальні дані.
Перевіряйте URL та параметри Після декодування перевіряйте формат URL та всі параметри, щоб переконатися, що вони відповідають вимогам додатку.
Уникайте подвійного кодування Переконайтесь, що вже закодовані URL не кодуються знову, оскільки це може призвести до порушення структури даних.
Використовуйте Pillow для обробки зображень Використовуйте Pillow для ефективної обробки зміни розміру, обрізки та конвертації форматів зображень в межах однієї обробки.
Тестуйте від початку до кінця Використовуйте інструменти, такі як інструменти розробника браузера, curl або Postman, для перевірки всього потоку від генерації URL на фронтенді до обробки на бекенді.

Висновок

Правильне кодування та декодування URL, разом з надійною обробкою зображень за допомогою Pillow, є важливими для створення ефективних та надійних веб-додатків. Виправляючи поширені проблеми, перевіряючи введені дані та використовуючи потужні інструменти, такі як Pillow, ви можете створювати безперебійні та масштабовані рішення для своїх користувачів. Пам'ятайте ці уроки для забезпечення плавного процесу розробки та надання високоякісних додатків.

Перекладено з: Fixing URL Encoding and Decoding Issues: Lessons from Real-World Web Applications