Ponowne wysyłanie WS
Ponowne wysyłanie WS tworzy sesje wielokrotnego użytku do testowania punktów końcowych WebSocket. Używaj go, aby łączyć się ponownie z przechwyconymi szczegółami uzgadniania połączenia, edytować wiadomości, wysyłać nowe ramki i obserwować odpowiedzi serwera.
Tworzenie sesji
Sesję ponownego wysyłania WebSocket można utworzyć na dwa sposoby:
- Kliknij przechwyconą wiadomość WebSocket prawym przyciskiem myszy w panelu Historia WS / SSE i wybierz Wyślij do panelu Ponowne wysyłanie WS.
- Otwórz Ponowne wysyłanie WS i ręcznie utwórz sesję z adresem URL
ws://lubwss://.
Sesje ręczne mogą zawierać niestandardowe nagłówki ciasteczek, tokenów autoryzacji, negocjacji protokołu lub wartości uzgadniania właściwych dla aplikacji.
Konfiguracja sesji
| Pole | Opis |
|---|---|
| Nazwa | Czytelna etykieta sesji. |
| URL | Punkt końcowy WebSocket. URL musi zaczynać się od ws:// lub wss://. |
| Nagłówki | Opcjonalne nagłówki uzgadniania wysyłane podczas łączenia. |
Jeśli zmienisz URL lub nagłówki, Ogma zapisze sesję przed otwarciem następnego połączenia.
Łączenie
Wybierz sesję i kliknij Połącz. Stan połączenia wskazuje, czy gniazdo jest rozłączone, łączy się, jest otwarte, zamyka się czy jest zamknięte.
Użyj Rozłącz przed zmianą celu lub szczegółów uzgadniania. Po edycji URL lub nagłówków połącz się ponownie, aby przetestować nową ścieżkę serwera lub kontekst uwierzytelnienia.
Połączenie kończy jedynie uzgadnianie WebSocket. Wiele aplikacji wymaga następnie ramki uwierzytelnienia lub inicjalizacji, zanim zaakceptuje wiadomości biznesowe. Użyj pierwszej przechwyconej wiadomości klienta jako punktu odniesienia, poczekaj na jej potwierdzenie i dopiero wtedy wyślij zmodyfikowaną wiadomość. Przechwycone ciasteczka, podpisane adresy URL i tokeny mogły wygasnąć.
Wysyłanie wiadomości
Użyj edytora wiadomości, aby zmienić ładunek i wysłać go przez wybraną sesję. Ładunki tekstowe są wysyłane jako tekstowe ramki WebSocket.
Przełącz na tryb binarny dla bajtów w zapisie szesnastkowym. Wyślij ponownie pierwszą przechwyconą wiadomość WebSocket pomaga odtworzyć inicjalizację, a Wyślij ponownie przechwyconą sekwencję wychodzącą wysyła przechwycone wiadomości klienta po kolei. Sprawdzaj odpowiedzi na osi czasu, zamiast zakładać, że wysłanie sekwencji odtworzyło stan aplikacji.
Edytor protokołu obsługuje surowy WebSocket i zarządzane tryby GraphQL (graphql-transport-ws oraz starszy graphql-ws). Wybierz protokół używany przez cel i podaj jego parametry połączenia. Zachowaj oryginalny nagłówek podprotokołu, gdy jest wymagany; żądanie niewłaściwego protokołu może uniemożliwić zmianę protokołu połączenia.
Aktualizuj znaczniki czasu jest domyślnie wyłączone. Włącz je tylko dla niepodpisanych żądań wymagających aktualnych znaczników czasu: zmiana podpisanego URL lub ładunku może unieważnić podpis. Automatyczne ponowne łączenie ponawia próbę po rozłączeniu, ale nowe połączenie nadal może wymagać uwierzytelnienia na poziomie aplikacji.
Wiadomości przesłane z historii zachowują oryginalny ładunek jako punkt wyjścia, dzięki czemu można zmieniać jedno pole naraz i porównywać działanie.
Oś czasu wiadomości
Oś czasu zapisuje wysłane i odebrane ramki wybranej sesji.
| Kolumna | Opis |
|---|---|
| Kierunek | Czy ramka została wysłana przez klienta, czy odebrana z serwera. |
| Kod operacji | Typ ramki, na przykład tekstowa, binarna, ping, pong lub zamknięcie. |
| Rozmiar | Rozmiar ładunku. |
| Czas | Kiedy Ogma zaobserwowała ramkę. |
Wybierz wiadomość, aby przeanalizować jej ładunek. Ładunki JSON są formatowane, gdy to możliwe; surowa zawartość pozostaje dostępna do dokładnego przeglądu.
Przebieg testowania
- Przechwyć normalną komunikację WebSocket w panelu Historia WS / SSE.
- Wyślij interesującą wiadomość klienta do panelu Ponowne wysyłanie WS.
- Połącz się ponownie i wyślij oryginalną wiadomość, aby potwierdzić zachowanie bazowe.
- Modyfikuj jedno pole, token, identyfikator lub polecenie naraz.
- Zapisz potwierdzone zachowanie w panelu Ustalenia lub prowadź notatki w panelu Notatki.
Rozwiązywanie problemów
| Objaw | Co sprawdzić |
|---|---|
| Zmiana protokołu odrzucona lub zabroniona | URL, Origin, ciasteczka, autoryzację i wygasłe podpisane wartości zapytania. |
| Nieprawidłowy lub nieżądany podprotokół | Porównaj nagłówki zmiany protokołu z przechwyconym uzgadnianiem i wybranym trybem protokołu. |
| Połączenie udaje się, a potem zamyka | Sprawdź wiadomość systemową lub zamknięcia i wyślij wymaganą ramkę inicjalizacji lub uwierzytelnienia. |
| Wiadomość wysłana, ale brak użytecznej odpowiedzi | Potwierdź identyfikatory subskrypcji, wcześniejsze wiadomości, uwierzytelnienie i stan aplikacji; transport WebSocket nie odtwarza automatycznie sesji przeglądarki. |
W MCP używaj dedykowanych narzędzi listowania i odczytu wiadomości oraz rozłączania sesji ponownego wysyłania WS. Narzędzia przechwyconej historii odczytują inny zapis komunikacji; zobacz dokumentację referencyjną narzędzi MCP.