Bu, birden çok kaynak isteğinin tek bir TCP oturumundan (ve SSL ile tek bir SSL oturumu) gelmesine izin veren HTTP canlı tutma ile ilgilidir. Bu, bir SSL sitesinin performansı için büyük önem taşır, çünkü canlı tutma olmadan, istenen her kaynak için bir SSL anlaşması gerekecektir.
Yani, buradaki endişe istemciden arka uç sunucusuna kadar büyük bir canlı oturum. Performans için önemli bir şey ve elbette modern HTTP sunucuları için ele alındı, ancak bu yama bunu desteklemediğini söylüyor. Bakalım neden ..
Canlı oturum, birbiri ardına yalnızca daha fazla istektir - sunucu bir isteğe yanıtını tamamladıktan sonra, sunucu FINTCP oturumunu sonlandırmak için bir paket göndermez; istemci başka bir başlık kümesi gönderebilir.
Bu yamanın ne yaptığını anlamak için, canlı bir sohbete bir örnek:
Müşteri:
GET / HTTP/1.1
Connection: keep-alive
Host: domain.com
...
Sunucu:
HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Server: Apache
Content-Length: 34
.... (other headers)
<html><head>content!</head></html>
Canlı olmayan bir bağlantının nerede duracağı burada. Ancak, canlı tutma, müşterinin bir başkasını ateşlemesine izin verir:
GET /images/some/image.on.the.page.jpg HTTP/1.1
Connection: keep-alive
Host: domain.com
...
Proxy'de istemci kimliği için X-Forwarded-For, her istemci isteğinde başlığa bazı ters proxy'ler eklenebilir . Bu, yukarı akış sunucusuna, günlüğe kaydetme ve diğer uygulama ihtiyaçları için akıl sağlığına yönelik isteğin nereden geldiğini (ters proxy'nin IP'sinden başlayan her istek yerine) gösterir.
X-Forwarded-ForBaşlık her ve Tam başlıklar her zaman gönderilir olarak, canlı tutma bağlantısı üzerinden gönderilen her istemci kaynak isteği enjekte edilmesi gerekmektedir; X-Forwarded-Forüstbilgi ve çevirinin "gerçek" istek olarak işlenmesi IP, TCP-canlı tutma oturumu başına değil, istek başına yapılır. Ve hey, belki birden fazla istemciden gelen isteklere hizmet vermek için tek bir canlı oturum kullanan bazı harika ters proxy yazılımı var.
Bu yama başarısız oluyor.
Bu sitedeki düzeltme eki, akıştaki ilk HTTP üstbilgi kümesinin sonu için TCP oturumunun arabelleğini izler ve ilk üstbilgi kümesinin bitiminden sonra yeni üstbilgiyi akışa enjekte eder. Bu yapıldıktan sonra, yapılan X-Forwarded-Forişi dikkate alır ve yeni başlık kümelerinin sonu için taramayı durdurur. Bu yöntemin, sonraki istekler yoluyla gelen gelecekteki tüm üstbilgiler hakkında hiçbir bilgisi yoktur.
Onları gerçekten suçlayamam; stunnel, akışlarının içeriğinin işlenmesi ve çevirisi için gerçekten inşa edilmemiştir.
Bunun sisteminiz üzerindeki etkisi, canlı tutma akışının ilk isteğinin X-Forwarded-Forbaşlığı düzgün bir şekilde enjekte etmesini ve sonraki tüm isteklerin iyi çalışmasını sağlar - ancak üstbilgileri olmaz.
Bağlantı başına birden fazla istemci isteğini işleyebilecek (veya Stack Overflow'daki arkadaşlarımızın yardımıyla bunu değiştirebilecek) başka bir başlık enjeksiyon yaması yoksa, SSL sonlandırmanız için diğer seçeneklere bakmanız gerekebilir.