eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.comp.wwwProblem z nagłówkami HTTP 1.1Re: Problem z nagłówkami HTTP 1.1
  • Data: 2009-10-02 19:29:31
    Temat: Re: Problem z nagłówkami HTTP 1.1
    Od: "Marek" <m...@s...interia.pl> szukaj wiadomości tego autora
    [ pokaż wszystkie nagłówki ]

    > Content-Length jest wielkością *po* kompresji.

    Po kompresji? :-0
    To mi szczęka opadła. Czy to oznacza, że albo stosujemy w PHP
    zlib.output_compression=ON albo nagłówek Content-Length ?

    Nie da się przewidzieć jakiej wielkości będzie plik po kompresji. W końcu
    najpierw posługujemy się header() a na końcu robimy print() i sam print
    kompresuje dane. Tak więc nie wiem ile danych opuści printa, a już w
    szczególności nie będę tego wiedział w chcwili gdy nagłówek wysyłam (czyli
    przed użyciuem printa).

    Ponadto zauważyłem, że chyba tak nie do końca jest jak napisałeś, albo źle
    interpretuję obserwacje. Otóż gdy nawet o 1 bajt źle wpiszę długość
    wiadomości to efekty tego doskonale widać w Fierbugu. Dzieją się cuda.
    GdyC-L jest za duży to przeglądarka długo wyczekuje reszty pliku, a gdt C-L
    jest za krótki - pliki graficzne są uszkodzone i nie wyświetlają się
    poprawnie. Tymczasem gdy ustawiam C-L na wartość przed kompresją, to
    wszystko działa ok. Może PHP modyfikuje ten nagłówek w tle?

    > Zapewne nie wysyła Accept-Encoding:gzip

    Tak, o to chodzi. Stąd diagnoza o tym, że FF oraz IE nie radzą sobie z tym w
    przypadku SWFów albo PHP uzależnia wielkość transmiscji od nagłówka C-L...

    >> A co do podawania Content-Length to raczej jest konieczność używania z
    >> uwagi na cache'owanie plików przez przeglądarkę.
    >
    > AFAIR wg RFC nie ma takiej konieczności.

    Wprost nie piszą ale "Applications SHOULD use this field to indicate the
    transfer-length of the message-body" a w domyśle (jako konsekwencja moich
    obserwacji) "bo w przeciwnym razie przeglądarki nie będą keszowały
    poprawnie".

    > Dorzuć Last-Modified, Cache-Control: max-age= albo Expires, obsługuj 304.
    > Poczytaj RFC 2616.

    Oczywiście bez wysyłania 304 nie pisałbym o cache'owaniu przecież :-) W/w
    nagłówki niczego nie dawały. Sęk w tym, że brak cacheowania polega na tym,
    że przeglądarka zaprzestaje wysyłania do serwera nagłówków, które pozwalają
    określić czy należy wysłać 304 czy 200. A tak się dzieje gdy wcześniej
    wysłany plik do przeglądarki jest ogołocony z nagłówka C-L i/lub Date. Wtedy
    np. Etag wysłany wraz z obrazkiem nie wraca do serwera przy odświeżaniu
    strony albo raz jest wysyłany a w przypadku innego pliku - nie jest. Jakaś
    losowość następuje - to również przyuważyłem.

Podziel się

Poleć ten post znajomemu poleć

Wydrukuj ten post drukuj


Następne wpisy z tego wątku

Najnowsze wątki z tej grupy


Najnowsze wątki

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: