Plik cookie utworzony przedstawionym poleceniem PHP:
setcookie("osoba", "Anna Kowalska", time() + (3600 * 24));
A. będzie przechowywany na serwerze przez jedną dobę.
B. wygaśnie po jednej godzinie od jego utworzenia.
C. wygaśnie po jednej dobie od jego utworzenia.
D. będzie przechowywany na serwerze przez jedną godzinę.
W tym poleceniu PHP funkcja setcookie() dostaje jako trzeci parametr czas wygaśnięcia ciasteczka w postaci znacznika czasu UNIX (timestamp). Wyrażenie time() + (3600 * 24) oznacza: aktualny czas serwera (time()) powiększony o 3600 sekund (czyli jedną godzinę) razy 24, co razem daje 86400 sekund, czyli dokładnie jedną dobę. Przeglądarka zapisuje to jako tzw. cookie trwałe (persistent cookie) i będzie je przechowywać do momentu osiągnięcia tego czasu. Po upływie doby od utworzenia, przeglądarka automatycznie przestanie wysyłać to cookie w nagłówkach HTTP do serwera. To jest ważne: cookie jest przechowywane po stronie klienta, czyli w przeglądarce użytkownika, a nie na serwerze. Serwer tylko wysyła nagłówek Set-Cookie w odpowiedzi HTTP. W praktyce takie ustawienie przydaje się np. do zapamiętania imienia użytkownika, preferencji językowych, koszyka w prostym sklepie albo ustawień wyglądu strony na krótki czas, np. na jedną dobę. Moim zdaniem warto zapamiętać, że brak trzeciego parametru w setcookie() oznacza cookie sesyjne (kasowane po zamknięciu przeglądarki), a podanie konkretnego timestampu tworzy cookie, które ma określoną datę wygaśnięcia. Dobrą praktyką jest zawsze świadomie dobierać czas życia ciasteczek: dane wrażliwe powinny mieć raczej krótki czas ważności, a informacje czysto techniczne lub preferencje interfejsu mogą być przechowywane dłużej. W nowoczesnych aplikacjach webowych łączy się to też z innymi atrybutami cookie (Secure, HttpOnly, SameSite), ale sam mechanizm czasu wygaśnięcia pozostaje taki sam – jest to po prostu liczba sekund od epoki UNIX, kiedy cookie przestanie być uznawane za ważne.
Kod z funkcją setcookie() w PHP bardzo często myli się z mechanizmami przechowywania danych po stronie serwera, dlatego łatwo tu o błędne skojarzenia. W tym przykładzie kluczowe są dwie rzeczy: po pierwsze, gdzie fizycznie przechowywane jest cookie, a po drugie, w jakiej jednostce podajemy czas. Ciasteczka HTTP są zawsze przechowywane po stronie klienta, czyli w przeglądarce użytkownika, w jej lokalnym magazynie. Serwer jedynie informuje przeglądarkę, jaki ma być czas życia takiego wpisu, wysyłając odpowiedni nagłówek Set-Cookie z datą wygaśnięcia. Stąd pomysł, że cookie „będzie przechowywane na serwerze” jest po prostu nietrafiony – serwer nie ma osobnego magazynu na ciasteczka użytkowników, on tylko je odczytuje z nagłówków przychodzących żądań i ewentualnie ustawia nowe. Druga częsta pomyłka dotyczy samego czasu. Funkcja time() zwraca aktualny timestamp w sekundach od 1.01.1970, a w wyrażeniu 3600 * 24 wyliczana jest liczba sekund w jednej dobie. Jeśli ktoś pobieżnie spojrzy na zapis, może skojarzyć 3600 z godziną i założyć, że cookie jest ważne tylko godzinę, ignorując mnożenie przez 24. To typowy błąd „czytania po łebkach” kodu. Tymczasem przeglądarka dostaje konkretny moment w przyszłości, przesunięty o 86400 sekund, i do tej chwili będzie wysyłać cookie przy każdym żądaniu do odpowiedniej domeny i ścieżki. Warto też pamiętać, że samo istnienie cookie nie oznacza trwałego przechowywania danych po stronie serwera. Dane z ciasteczka trafiają na serwer dopiero, gdy przeglądarka wyśle je w nagłówku HTTP. Dlatego planując logikę aplikacji, trzeba jasno rozróżniać dane sesyjne na serwerze (np. w $_SESSION) od danych w cookie, które użytkownik może modyfikować po swojej stronie i które wygasają dokładnie według tego timestampu, jaki podamy w setcookie().