Wyniki wyszukiwania "http"

Plik z zasadami dla AI piszesz raz, a agent pracuje według niego miesiącami - także wtedy, gdy połowa zasad przestała być prawdą. W badaniu METR z początku 2025 doświadczeni programiści z AI byli wolniejsi o 19%, choć czuli się szybsi o 20%. W tym poście pokazuję, jak to u siebie rozwiązałem. Instrukcje trafiły pod tę samą kontrolę co kod, dostały własną bramkę, a bramka dostała test, który ją sprawdza.

Odpowiedź AI pojawia się stopniowo nie przez efekt wizualny, tylko przez streaming: ciało odpowiedzi HTTP jest strumieniem, więc serwer może odsyłać je kawałkami, a przeglądarka pokazywać każdy od razu. Na froncie czyta się to na dwa sposoby - prościutkim EventSource (SSE) albo elastycznym fetch ze strumieniem - i dokładnie tego drugiego używają pod spodem biblioteki do LLM-ów.

Ta sama odpowiedź serwera może w jednej chwili leżeć w kilku cache'ach naraz - pamięci aplikacji, Service Workerze, cache HTTP, na CDN - a całą stronę trzyma jeszcze bfcache. Każdy ma innego właściciela i co innego go czyści, więc „wyczyść cache" trafia w jeden z nich, czasem w żaden. Zostaje pytanie, od którego zaczyna się każde takie debugowanie: która warstwa trzyma starą kopię i co ją unieważnia.

Weź jeden plik style.css i prześledź jego dzień na działającej stronie: najpierw pobiera go przeglądarka, potem serwuje go z pamięci bez pytania serwera, później pyta serwer, czy jej kopia jest nadal aktualna, i zwykle dostaje samo potwierdzenie zamiast całego pliku, a po wdrożeniu nowej wersji pobiera go od nowa. Z tej jednej historii wychodzi cały HTTP caching - Cache-Control, ETag, 304 i stale-while-revalidate.

Same-origin policy (SOP) w przeglądarce blokuje kod JavaScript z jednej strony przed czytaniem danych z innej domeny - chyba że serwer wprost pozwoli przez CORS. W poście opisuję, jak działa ten mechanizm zgody serwera i czemu czasem widzisz preflight OPTIONS, a czasem nie.