Nagłówek warunkowy nie został spełniony.
Kiedy go używać
If-Match z nieaktualnym ETagiem, aby zapobiec utracie aktualizacji.
Typowe przyczyny i rozwiązania
412 oznacza, że warunek dołączony przez klienta nie został spełniony. Zwykle chodzi o If-Match z ETagiem, który już nie pasuje, bo ktoś inny zaktualizował zasób pierwszy, a serwer odmawia nadpisania jego zmiany. Klient powinien pobrać GET-em bieżącą wersję, scalić zmiany lub zapytać użytkownika, a potem ponowić żądanie z nowym ETagiem. If-Unmodified-Since robi to samo z datami.
If-Match wymaga silnego porównania, więc słabe ETagi z prefiksem W/ nigdy nie pasują, a proxy kompresujące odpowiedzi mogą osłabiać ETagi, przez co każdy zapis kończy się 412. Działa to też odwrotnie: If-None-Match: * przy PUT sprawia, że utworzenie kończy się 412, gdy zasób już istnieje, co jest tanim zabezpieczeniem przed nadpisaniem. S3 i Google Cloud Storage również używają 412 przy zapisach warunkowych.
Błąd klienta (4xx)
Kody 4xx to błędy klienta: samo żądanie jest błędne, nieautoryzowane albo wskazuje na coś, czego nie ma. Ponowienie tego samego żądania nic nie da.
Jak to wygląda
HTTP/1.1 412 Precondition FailedJak go wysłać
| Node.js / Express | res.status(412).end() |
|---|---|
| Python / Flask | return '', 412 |
| nginx | return 412; |
Jak go sprawdzić
curl -s -o /dev/null -w "%{http_code}\n" https://example.com/