Приклади 302 проти 303

Чим відрізняється а 302та 303відповідь?

http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

• 10.3.3 Знайдено 302
• 10.3.4 303 Див. Інше

Вони взаємозамінні або чому один використовувався б над іншим? Чи можете ви надати, будь ласка, випадок використання, коли один буде використовуватися (а другий - ні)?

Опис на сторінці, на яку ви пов’язали, здається, досить описує їх призначення:

Переадресація 302 вказує на те, що переспрямування є тимчасовим - клієнти повинні перевірити вихідну URL-адресу в майбутніх запитах.

Переадресація 303 призначена для перенаправлення POSTзапиту на GETресурс (інакше клієнт припускає, що метод запиту для нового місцезнаходження такий же, як і для вихідного ресурсу).

Якщо ви переспрямовуєте клієнта як частину свого веб-додатку, але очікуєте, що він завжди запускається у веб-додатку (наприклад, укорочувач URL-адрес), перенаправлення 302, здається, має сенс. Переадресація 303 використовується для отримання POSTданих від клієнта (наприклад, подання форми), і ви хочете перенаправити їх на нову веб-сторінку, яку слід отримати GETзамість POST(наприклад, стандартний запит на сторінку).

Але дивіться цю примітку з визначень коду статусу - більшість клієнтів будуть робити те ж саме для 302 або 303:

  Note: RFC 1945 and RFC 2068 specify that the client is not allowed
  to change the method on the redirected request.  However, most
  existing user agent implementations treat 302 as if it were a 303
  response, performing a GET on the Location field-value regardless
  of the original request method. The status codes 303 and 307 have
  been added for servers that wish to make unambiguously clear which
  kind of reaction is expected of the client.

Існує чотири різні типи переадресації (зараз). Спочатку було лише два, але більшість клієнтів реалізували переспрямування 302 неправильно, тому ще два були додані для уточнення різниці між двома різними можливими способами поведінки при отриманні 302.

RFC, з яким ви пов’язані, заявляє це у розділі про 302 переадресації:

  Note: RFC 1945 and RFC 2068 specify that the client is not allowed
  to change the method on the redirected request.  However, most
  existing user agent implementations treat 302 as if it were a 303
  response, performing a GET on the Location field-value regardless
  of the original request method. The status codes 303 and 307 have
  been added for servers that wish to make unambiguously clear which
  kind of reaction is expected of the client.

1. Переадресація 301 - це постійне переадресація. Це кеш-пам'ять, і будь-які закладки для цієї URL-адреси повинні бути оновлені, щоб вказувати на нову URL-адресу.
2. Переадресація 302 - тимчасова переадресація. За замовчуванням він не підлягає кешуванню, і його потрібно повторно запитувати (але ви можете замінити це заголовок кешування). Наступний запит повинен використовувати той самий метод (POST, GET, CONNECT, PUT, DELETE тощо), як і оригінальний запит, і для будь-якого іншого, крім GET та HEAD запитів, клієнт повинен сповістити користувача перед тим, як зробити запит. Це частина того, що клієнти помилилися, і більшість з них змінюють метод подальших запитів на GET, незалежно від оригінального методу.
3. Переадресація 303 така ж, як і 302, за винятком того, що подальший запит тепер явно змінено на GET-запит, і підтвердження не потрібно.
4. Переадресація 307 - це те саме, що і 302, за винятком того, що запит на подальший контроль явно такий же, як оригінальний запит, і підтвердження повинно бути отримано від користувача для інших способів запиту, окрім GET та HEAD.

Старі клієнти можуть не розуміти переспрямування 303. Все, що робить запит HTTP / 1.1, має розуміти відповідь 303.

Можливо вважати, що 300 та 305 відповідей є перенаправленнями, тобто існує шість різних типів.

Типи переадресації (301,302,303 ...) мають великий вплив на те, як пошукові системи будуть індексувати та класифікувати вміст. Деякі павуки можуть навіть відмовитись від індексації тимчасово перенаправленого вмісту. Деталі можна знайти в різноманітній SEO літературі ...