Autor: Bezstanowy serwer MCP: co zmieniła aktualizacja protokołu
Aktualizacja MCP z 2026-07-28 usunęła sesje oraz handshake initialize. Dowiedz się, jak te zmiany wpływają na konfigurację reverse proxy, health checks, limity czasu i autoryzację.
Czym jest bezstanowy serwer MCP
Bezstanowy serwer MCP nie przechowuje stanu poszczególnych klientów pomiędzy żądaniami. Każde żądanie zawiera wersję protokołu, możliwości klienta oraz poświadczenia niezbędne serwerowi do udzielenia odpowiedzi, dzięki czemu dowolny proces na dowolnej maszynie może obsłużyć każde żądanie. MCP (Model Context Protocol, format komunikacji używany przez agentów do uzyskiwania dostępu do narzędzi) wprowadził tę zasadę w wersji 2026-07-28, która usunęła uzgadnianie initialize oraz sesję HTTP działającą w jego warstwie. Treść tego dokumentu dotyczy strony serwerowej tego protokołu, więc jeśli strona kliencka (agenta) jest nowym zagadnieniem, uporządkowana ścieżka nauki o agentach AI omawia pętlę decyzyjną wywołania narzędzia, zanim jakiekolwiek szczegóły HTTP staną się istotne.
To jest główny cel operacyjny. Serwer, który nie przechowuje stanu klienta, może działać za standardowym load balancerem bez konieczności stosowania sesji typu sticky, może być restartowany podczas wdrażania bez przerywania pracy klientów i może działać jako cztery identyczne procesy zamiast jednego. Serwer oparty na sesjach nie oferuje żadnej z tych możliwości bez dodatkowej infrastruktury.
Model Context Protocol jest protokołem bezstanowym: wszystkie informacje potrzebne do przetworzenia żądania znajdują się w samym żądaniu. Serwer przetwarza każde żądanie niezależnie; żaden stan nie powinien być wnioskowany z poprzednich żądań, nawet tych pochodzących z tego samego połączenia lub strumienia.
Bezstanowość nie oznacza, że serwer niczego nie przechowuje. Baza danych, kolejka i pamięć podręczna nadal działają. Oznacza to, że protokół nie przenosi stanu w ramach połączenia. Serwer nie może więc traktować połączenia, procesu ani otwartego gniazda jako odpowiednika „tego klienta w trakcie rozmowy”. Najłatwiej zobaczyć tę różnicę w aplikacji, która już zarządza własnymi danymi: tylko do odczytu serwer MCP openGym odpowiada na pytania dotyczące historii treningów zapisanej w bazie danych aplikacji, a sposób przechowywania tych danych nie zależy od połączenia, przez które dotarło konkretne żądanie.
Co usunięto w wersji 2026-07-28
2026-07-28 to bieżąca wersja specyfikacji na sierpień 2026 roku. W porównaniu z 2025-11-25 usunięto pięć elementów, które istniały w celu obsługi sesji.
- Żądanie
initializeoraz powiadomienienotifications/initialized. Całkowicie zrezygnowano z uzgadniania połączenia (SEP-2575). - Nagłówek
Mcp-Session-Idoraz kończenie sesji za pomocą HTTPDELETE(SEP-2567). - Samodzielny strumień HTTP
GET, przez który serwery przesyłały powiadomienia. Został on zastąpiony przezsubscriptions/listen, czyli zwykłe żądanie POST, którego odpowiedź jest strumieniem długotrwałym. - Możliwość wznawiania strumieni SSE (server-sent events). Nagłówek
Last-Event-IDoraz identyfikatory poszczególnych zdarzeń zostały usunięte, więc zerwany strumień powoduje utratę bieżącego żądania, a klient musi ponowić je jako nowe żądanie z nowym identyfikatorem. ping,logging/setLeveloraznotifications/roots/list_changed. Poziom logowania jest teraz polem wewnątrz żądania,io.modelcontextprotocol/logLevelw_meta.
Dodano jedną metodę, którą musi zaimplementować każdy serwer. server/discover zwraca obsługiwane przez serwer wersje protokołu, możliwości oraz identyfikator w jednym wywołaniu. Jest to najbliższy odpowiednik uzgadniania połączenia, jaki pozostał, a jego wywoływanie przez klientów jest opcjonalne.
Dlaczego transport sesji był trudny do uruchomienia w środowisku produkcyjnym
W wersji 2025-11-25 i wcześniejszych serwer mógł wygenerować identyfikator sesji podczas inicjalizacji i zwrócić go w nagłówku Mcp-Session-Id w odpowiedzi InitializeResult. Klient musiał następnie przesyłać ten nagłówek w każdym kolejnym żądaniu. Wynegocjowana wersja protokołu oraz możliwości klienta były przechowywane w pamięci serwera, przypisane do tego identyfikatora. Każdy z tych wyborów wiąże się z kosztami operacyjnymi.
- Restart serwera powodował utratę tabeli sesji. Specyfikacja wymagała, aby serwer odpowiadał na każde żądanie zawierające nieaktywny identyfikator sesji błędem
404 Not Found, a klient musiał rozpoczynać proces od nowa za pomocą nowegoInitializeRequest. Każde wdrożenie stawało się zdarzeniem wymagającym ponownego połączenia dla każdego podłączonego klienta. - Druga replika nie posiadała informacji o sesjach pierwszej repliki. Skalowanie poziome wymagało stosowania mechanizmu sticky sessions na load balancerze lub współdzielonego magazynu sesji, z którego każda replika korzystała przy każdym żądaniu.
- Tabela sesji była pamięcią, której zużycie rosło wraz z liczbą bezczynnych klientów. Mechanizm
DELETEbył opcjonalny, a klienci, którzy zamykali połączenie bez jego wysłania, pozostawiali w pamięci niepotrzebne wpisy. - Wyniki listowania mogły różnić się w zależności od połączenia, co sprawiało, że buforowanie przed serwerem było niebezpieczne.
Usunięcie sesji eliminuje wszystkie cztery problemy jednocześnie. Jest to zmiana, którą warto zrozumieć przed przystąpieniem do jakiejkolwiek modyfikacji konfiguracji.
Co zawiera teraz każde żądanie
Każdy POST do punktu końcowego MCP jest niezależny. Wersja protokołu oraz możliwości klienta są przesyłane w treści żądania w ramach _meta, a wybrane pola są kopiowane do nagłówków HTTP, aby pośrednik mógł na ich podstawie kierować ruch bez parsowania JSON.
POST /mcp HTTP/1.1
Content-Type: application/json
Accept: application/json, text/event-stream
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: get_weather
Authorization: Bearer <access token>
{
"jsonrpc": "2.0",
"id": 1,
"method": "tools/call",
"params": {
"name": "get_weather",
"arguments": {"location": "Seattle, WA"},
"_meta": {
"io.modelcontextprotocol/protocolVersion": "2026-07-28",
"io.modelcontextprotocol/clientInfo": {"name": "ExampleClient", "version": "1.0.0"},
"io.modelcontextprotocol/clientCapabilities": {}
}
}
}io.modelcontextprotocol/protocolVersion oraz io.modelcontextprotocol/clientCapabilities są wymagane w każdym żądaniu. clientInfo nie jest wymagane, choć klienci powinni je przesyłać. Żądanie, w którym brakuje wymaganego pola, jest błędne, dlatego serwer musi je odrzucić z błędem JSON-RPC -32602 oraz kodem HTTP 400 Bad Request.
Nagłówek Mcp-Method jest wymagany w każdym żądaniu. Mcp-Name jest wymagane w tools/call, resources/read oraz prompts/get. Wartość nagłówka musi być zgodna z treścią żądania, a serwer przetwarzający treść musi odrzucić niezgodność za pomocą 400 Bad Request oraz kodu błędu -32020, HeaderMismatch. Zasada ta istnieje, ponieważ równoważnik obciążenia kierujący ruch na podstawie nagłówka oraz serwer wykonujący operację na podstawie treści to dwa różne źródła prawdy. W przypadku kierowania ruchu lub ograniczania częstotliwości (rate-limiting) na podstawie tych nagłówków, należy najpierw sprawdzić MCP-Protocol-Version: wcześniejsze wersje nigdy nie weryfikowały nagłówka względem treści, więc w tamtych wersjach wartość nagłówka nie jest wiarygodna.
Niezgodność wersji jest teraz zwykłym błędem dotyczącym pojedynczego żądania, a nie nieudanym uzgadnianiem (handshake). Serwer, który nie obsługuje żądanej wersji, odpowiada 400 Bad Request z błędem -32022, UnsupportedProtocolVersion i wymienia obsługiwane wersje w data.supported. Klient wybiera jedną z nich z listy i ponawia próbę.
Gdzie podział się stan: tokeny, kursory, subskrypcje
Stan nie zniknął. Przeniósł się w miejsca, które można obserwować i logować.
Poświadczenia są przesyłane w każdym żądaniu. Nie istnieje sesja, do której można przypisać tożsamość, więc token dostępu towarzyszy każdemu wywołaniu HTTP i jest za każdym razem weryfikowany. Szczegóły znajdują się w sekcji dotyczącej uwierzytelniania poniżej.
Kursory muszą przenosić własną pozycję. Stronicowanie w tools/list, resources/list, prompts/list oraz resources/templates/list wykorzystuje nieprzejrzysty ciąg znaków kursora, którego klient nie powinien parsować ani modyfikować. Na serwerze jednowątkowym powszechną praktyką było przechowywanie offsetu w pamięci, powiązanego z sesją. Przy braku sesji kursor musi zawierać wystarczające informacje, aby dowolna replika mogła wznowić listowanie, dlatego należy zakodować pozycję wewnątrz kursora i podpisać ją lub przechowywać w pamięci współdzielonej przez wszystkie repliki. Nieprawidłowy kursor powinien skutkować zwróceniem -32602. Podpisuj kursor, ponieważ nieprzejrzysty ciąg jest danymi wejściowymi dostarczanymi przez klienta, które kod dekoduje i uznaje za zaufane.
Subskrypcje należą do żądania, a nie do połączenia. Klient oczekujący powiadomień o zmianach wysyła subscriptions/listen z filtrem określającym typy, które go interesują: toolsListChanged, promptsListChanged, resourcesListChanged oraz resourceSubscriptions. Serwer odpowiada za pomocą notifications/subscriptions/acknowledged i utrzymuje ten strumień odpowiedzi otwarty. Jeśli strumień zostanie przerwany, serwer nie przechowuje żadnych informacji, a klient wysyła ponownie subscriptions/listen, aby przywrócić subskrypcję.
Stan aplikacji między wywołaniami staje się jawnym uchwytem. Gdy serwer musi zapamiętać coś pomiędzy wywołaniami, specyfikacja przewiduje użycie identyfikatora wygenerowanego przez serwer, przekazywanego jako zwykły argument narzędzia. Pojawia się on w schemacie narzędzia, może być logowany i nigdy nie jest domyślnie powiązany z połączeniem. Serwer obsługujący rzeczywiste dane użytkownika, taki jak własny serwer MCP poczty e-mail, stosuje ten wzorzec zamiast sesji: identyfikator skrzynki odbiorczej lub szkicu jest argumentem narzędzia, dzięki czemu każda replika może obsłużyć kolejne wywołanie. Wiele narzędzi w ogóle nie potrzebuje uchwytu: narzędzie wyszukiwania oparte na własnej instancji SearXNG przyjmuje zapytanie i zwraca wyniki, nie wymagając wznawiania stanu przy kolejnym wywołaniu i nie dbając o to, która replika udzieliła odpowiedzi.
Wdrożenie: reverse proxy, limity czasu, sprawdzanie stanu (health checks)
Punkt końcowy MCP to jedna ścieżka akceptująca metodę POST. Większość ruchu to krótkie żądania i odpowiedzi JSON, które każde proxy obsługuje bez problemów. Wyjątkiem jest odpowiedź strumieniowa, w przypadku której domyślne ustawienia proxy mogą działać na niekorzyść. Jest to element, który zmienia się podczas przenoszenia rozwiązania z lokalnego środowiska testowego na serwer MCP działający na VPS.
location /mcp {
proxy_pass http://127.0.0.1:8080;
proxy_http_version 1.1;
proxy_set_header Connection "";
proxy_set_header Host $host;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_buffering off;
proxy_read_timeout 1h;
proxy_send_timeout 1h;
}proxy_buffering off ma znaczenie, ponieważ nginx domyślnie buforuje odpowiedzi proxy, co wstrzymuje zdarzenia SSE do momentu zapełnienia bufora lub zakończenia odpowiedzi. Specyfikacja wymaga również, aby serwery wysyłały X-Accel-Buffering: no w odpowiedziach SSE, a nginx respektuje ten nagłówek, więc poprawnie skonfigurowany serwer przekaże proxy odpowiednie instrukcje. Należy jednak ustawić tę dyrektywę samodzielnie, ponieważ jest to element pozostający pod kontrolą administratora.
proxy_read_timeout domyślnie wynosi 60 sekund. Strumień subscriptions/listen, w którym przez dłuższy czas nie występuje aktywność, jest zamykany przez nginx, a nie przez serwer. W rezultacie logi wskazują na poprawnie działający proces, podczas gdy klient zgłasza zerwanie strumienia. Wartość tę należy zwiększyć wyłącznie dla lokalizacji MCP, a nie dla całego serwera. Zaleca się również, aby serwery wysyłały linię komentarza SSE (linię rozpoczynającą się od dwukropka) jako sygnał keep-alive w okresach bezczynności, co zapobiega przerywaniu strumienia przez pośredników.
Caddy wymaga mniej konfiguracji. Domyślnie stosuje częściowe buforowanie w celu zwiększenia wydajności przesyłu i natychmiastowo opróżnia bufor, gdy odpowiedź zawiera Content-Type: text/event-stream, dzięki czemu strumieniowanie działa bez dodatkowych dyrektyw.
mcp.example.com {
reverse_proxy 127.0.0.1:8080 {
health_uri /healthz
health_interval 10s
}
}Należy zwrócić uwagę na cel sprawdzania stanu (health check). Nie należy kierować aktywnego sprawdzania na punkt końcowy MCP przy użyciu GET, ponieważ serwer implementujący tylko tę wersję odpowiada 405 Method Not Allowed na GET oraz DELETE, a domyślną metodą sprawdzania w Caddy jest GET. Proxy oznaczyłoby wtedy w pełni sprawny backend jako niedostępny. Należy udostępnić prostą ścieżkę, taką jak /healthz, na potrzeby proxy, a weryfikację protokołu przeprowadzać oddzielnie za pomocą metody POST.
curl -sS https://mcp.example.com/mcp \
-H 'Content-Type: application/json' \
-H 'Accept: application/json, text/event-stream' \
-H 'MCP-Protocol-Version: 2026-07-28' \
-H 'Mcp-Method: server/discover' \
-d '{"jsonrpc":"2.0","id":"health-1","method":"server/discover","params":{"_meta":{"io.modelcontextprotocol/protocolVersion":"2026-07-28","io.modelcontextprotocol/clientCapabilities":{}}}}'Odpowiedź 200 zawierająca listę supportedVersions oznacza, że proces działa i obsługuje protokół. Odpowiedź 404 z błędem JSON-RPC -32601 oznacza, że proces działa, ale nie obsługuje server/discover, co jest wymagane od każdego serwera 2026-07-28. Odpowiedź 400 z -32022 oznacza, że sprawdzający zażądał wersji nieobsługiwanej przez daną kompilację, co pozwala wykryć problemy po aktualizacji zależności. Wersja open source nginx nie posiada funkcji aktywnego sprawdzania stanu, dlatego należy stosować pasywne max_fails i fail_timeout w sekcji upstream, a weryfikację protokołu zlecić zewnętrznemu systemowi monitorowania.
Restart typu rolling update powoduje obecnie utratę jedynie aktualnie przetwarzanych żądań. Należy odczekać na zakończenie otwartych żądań POST, uruchomić nowy proces, a klienci automatycznie ponowią nieudane operacje. Jedynym elementem, który zostanie przerwany, jest otwarty strumień subscriptions/listen, ponieważ jest to aktywne połączenie z konkretnym procesem. Bezstanowość wyeliminowała potrzebę powinowactwa sesji (session affinity), ale nie wyeliminowała powinowactwa połączenia dla otwartego strumienia, czego nie naprawi żadna reguła routingu. Klient może rozpoznać tę sytuację: strumień zakończony pustym wynikiem subscriptions/listen został zamknięty poprawnie, natomiast strumień zakończony nagle został przerwany, co dla klienta stanowi przesłankę do ponownego nawiązania połączenia.
Możliwe staje się również buforowanie. Wyniki metod listowania zawierają teraz ttlMs oraz cacheScope, a cacheScope: "public" informuje współdzielonych pośredników, że mogą buforować odpowiedź. Jest to bezpieczne tylko dlatego, że wyniki listowania nie różnią się już w zależności od połączenia, co jest bezpośrednim skutkiem usunięcia sesji.
Dlaczego uwierzytelnianie zmienia się w przypadku braku sesji
W modelu z sesją kuszące było uwierzytelnienie raz w initialize, a następnie traktowanie identyfikatora sesji jako dowodu dla wszystkich kolejnych działań. Identyfikator sesji użyty w ten sposób jest poświadczeniem typu bearer bez określonego odbiorcy, daty wygaśnięcia ani ścieżki unieważnienia, wygenerowanym przez własny serwer. Usunięcie sesji eliminuje ten skrót, a rozwiązanie zastępcze jest bardziej rygorystyczne.
Zabezpieczony serwer MCP działa jako serwer zasobów OAuth 2.1. Każde żądanie HTTP od klienta musi zawierać Authorization: Bearer <access token>, a serwer weryfikuje token przy każdym żądaniu. Walidacja obejmuje odbiorcę: serwer musi potwierdzić, że token został wystawiony specjalnie dla niego, zgodnie z RFC 8707 (Resource Indicators for OAuth 2.0), i nie może akceptować ani przekazywać tokenów przeznaczonych dla innych celów. Klienci żądają odpowiedniego odbiorcy, wysyłając parametr resource z kanonicznym URI serwera.
Wykrywanie opiera się na wyzwaniu. Gdy nadejdzie żądanie bez użytecznego tokena, serwer odpowiada 401 Unauthorized.
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource",
scope="files:read"Klient odczytuje resource_metadata, pobiera ten dokument (RFC 9728, OAuth 2.0 Protected Resource Metadata, który serwery MCP muszą implementować), znajduje serwer autoryzacji i uruchamia przepływ. Prawidłowy token z niewystarczającymi uprawnieniami otrzymuje 403 Forbidden wraz z error="insufficient_scope" oraz zakresami (scopes) wymaganymi do wykonania danej operacji.
Pociąga to za sobą dwie konsekwencje dla sposobu eksploatacji. Walidacja tokena odbywa się teraz przy każdym żądaniu, a nie raz na sesję, więc sieciowy czas odpowiedzi (round trip) do punktu końcowego introspekcji przy każdym wywołaniu wpłynie na opóźnienia: należy preferować tokeny, które można zweryfikować lokalnie na podstawie podpisu, odbiorcy i daty wygaśnięcia, lub buforować wynik walidacji przez krótki czas, używając tokena jako klucza. Ponieważ nie ma sesji przechowującej tożsamość, autoryzacja musi być obliczana na podstawie tokena przy każdym wywołaniu. Jest to podejście bardziej rzetelne niż model sesyjny i łączy się z szerszą praktyką utrzymywania poświadczeń poza procesem agenta, co zostało omówione w utrzymywanie sekretów poza agentem AI. Zakresy (scopes) ograniczają jedynie to, co token może zrobić po dotarciu żądania do serwera; na maszynie, na której działa agent, wykorzystanie wtyczek dodających reguły uprawnień narzędzi i limity budżetowe decyduje o tym, czy wywołania w ogóle zostaną wykonane.
Co jest prawdą w odniesieniu do tej wersji, a co nie
Powyższy opis dotyczy wyłącznie wersji 2026-07-28. Nie opisuje on MCP w sposób ciągły ani serwera wdrożonego w ubiegłym roku.
Klienci i serwery w wersji 2025-11-25 oraz starszych nadal korzystają z modelu uzgadniania (handshake). Specyfikacja określa te wersje jako starsze (legacy), a wersje z metadanymi dla każdego żądania jako nowoczesne. Serwer obsługujący tylko tę wersję, po napotkaniu starszego klienta, powinien odpowiedzieć 405 Method Not Allowed na GET lub DELETE w punkcie końcowym MCP, zignorować każdy nagłówek Mcp-Session-Id bez jego tworzenia lub odsyłania oraz zignorować Last-Event-ID, ponieważ strumienie nie obsługują wznawiania. Serwer dwusystemowy może obsługiwać oba modele w jednym punkcie końcowym: żądanie zawierające nowoczesny nagłówek _meta jest obsługiwane bezstanowo, natomiast żądanie initialize wybiera starszą semantykę sesji.
Przed zastosowaniem powyższych informacji należy sprawdzić ciąg wersji. Jeśli używany SDK nadal wysyła initialize, sesje pozostają aktywne w danym wdrożeniu, a problemy związane z sesjami nadal wymagają obsługi. To samo dotyczy strony klienckiej: proces agenta na własnej maszynie, taki jak konfiguracja opisana w uruchamianie agenta programistycznego na VPS, jest bezstanowy w tym sensie tylko wtedy, gdy używana biblioteka obsługuje nowoczesną wersję. Należy odczytać wersję negocjowaną przez środowisko uruchomieniowe, sprawdzić odpowiadającą jej wersję specyfikacji i traktować tę stronę jako opis konkretnej wersji, a nie protokołu jako całości.
FAQ
Czy bezstanowy serwer MCP oznacza, że nie mogę niczego przechowywać?
Nie. Bezstanowość opisuje protokół, a nie aplikację. Bazy danych, kolejki i pamięci podręczne działają dokładnie tak samo jak wcześniej. Zmienia się to, że stan obejmujący kilka wywołań musi być wskazywany przez jawny identyfikator przekazywany przez klienta w każdym żądaniu, na przykład uchwyt wygenerowany przez serwer w argumencie narzędzia. Nie wolno natomiast wnioskować o kontekście na podstawie połączenia: specyfikacja stanowi, że serwer nie może polegać na poprzednich żądaniach w ramach tego samego połączenia w celu ustalenia możliwości, wersji protokołu lub tożsamości klienta, ponieważ każde żądanie dostarcza te dane w _meta.
Czy nadal potrzebuję sesji typu sticky na moim load balancerze?
Nie w przypadku zwykłych żądań. Zgodnie z wersją 2026-07-28 każde żądanie POST przenosi własną wersję protokołu, możliwości i poświadczenia, więc każda replika może odpowiedzieć na każde żądanie, a algorytm round-robin jest w pełni wystarczający. Jedynym długotrwałym elementem pozostaje strumień odpowiedzi subscriptions/listen, który jest pojedynczym otwartym połączeniem do jednego procesu. Kończy się ono wraz z zakończeniem procesu, a klient wysyła ponownie subscriptions/listen, aby je przywrócić. Jest to czas życia połączenia, a nie powinowactwo sesji, i żadna reguła routingu nie zapobiega takiemu działaniu.
Co stało się z Mcp-Session-Id oraz strumieniem HTTP GET?
Oba elementy zostały usunięte w wersji 2026-07-28, zgodnie z SEP-2567 oraz SEP-2575. Serwer implementujący wyłącznie tę wersję powinien odpowiadać 405 Method Not Allowed na GET oraz DELETE w punkcie końcowym MCP i powinien ignorować nagłówek Mcp-Session-Id zamiast odsyłać go w odpowiedzi. Powiadomienia o zmianach inicjowane przez serwer przesyłane są teraz w strumieniu odpowiedzi żądania subscriptions/listen zamiast w samodzielnym strumieniu GET. Serwery, które muszą nadal obsługiwać starszych klientów, implementują zachowanie wcześniejszej wersji równolegle z obecną.
Jak przeprowadzić kontrolę stanu serwera MCP bez handshake'u?
Należy zastosować dwa poziomy kontroli. Aktywną kontrolę proxy należy skierować na zwykłą ścieżkę HTTP obsługiwaną przez aplikację, ponieważ GET do punktu końcowego MCP poprawnie zwraca 405 i oznaczyłoby zdrowy backend jako niedostępny. Następnie należy sprawdzić sam protokół poprzez wysłanie POST server/discover, co musi implementować każdy serwer 2026-07-28, i zweryfikować, czy odpowiedź to HTTP 200 oraz czy zawiera wersję protokołu używaną przez klientów. Kod 404 z błędem JSON-RPC -32601 oznacza, że proces działa, ale nie obsługuje tej metody, natomiast 400 z -32022 oznacza, że żądana wersja nie jest wspierana przez daną kompilację.