Hacker DirectoryHacker Directory
Öğrenmeye devam et
ENHTML kaydet ↓

WEB / WEB-08.01

HTTP/1.x connection ve framing

Tek TCP byte stream üzerinde mesajın bitişini ve response sırasını ayrı izle. Persistence yeni exchange’e izin verir; pipelining response’ları birbirine karıştırmaz.

CORE · RED · BLUE · ARTIFACT · PRACTICE

1. Core · Mekanizma

Hareket olmadan bütün senaryoları oku

Pipeline sırası

  1. İki GET hazır

    Client aynı open connection’da A ve B GET’ini response beklemeden göndermeyi seçer.

    Client / Duru
    GET A /atlas-notes ve B /tea hazır; response bekleniyor
    Atlas server
    No requests
    Yerel connection state
    conn-h1 open
  2. A request ulaştı

    Server ilk complete GET’i A olarak alır; henüz Browser’da response veya status yoktur.

    Client / Duru
    GET A /atlas-notes ve B /tea hazır; response bekleniyor
    Atlas server
    A received
    Yerel connection state
    conn-h1 open
  3. B request ulaştı

    B request’i A’nın response’u beklenmeden ulaşır; receive sırası artık A ardından B’dir.

    Client / Duru
    GET A /atlas-notes ve B /tea hazır; response bekleniyor
    Atlas server
    A/B received
    Yerel connection state
    conn-h1 open
  4. B hazır, A pending

    Local scheduling B response’unu önce hazırlar; response-order kuralı B’yi kuyrukta tutar.

    Client / Duru
    No response yet
    Atlas server
    B ready; A pending
    Yerel connection state
    Prepared order: B
  5. A da hazır

    A response’u da hazırdır. Server hazırlık sırasını değil request sırasını izlemek zorundadır: önce A’nın 10 byte content’i, ardından B’nin 4 byte content’i gönderilecektir.

    Client / Duru
    No response yet
    Atlas server
    A CL10 ve B CL4 hazır; A önce
    Yerel connection state
    Prepared order: B,A
  6. A response ulaştı

    İlk complete response 10 content byte içerir; parser A’yı kapatıp B’nin message sınırına geçer.

    Client / Duru
    A complete: Atlas note
    Atlas server
    A delivered; B ready
    Yerel connection state
    conn-h1 open
  7. B response ulaştı

    İkinci complete response Çay’ın dört UTF-8 byte’ını taşır; arrival sırası A/B olarak korunur.

    Client / Duru
    A/B complete; B: Çay
    Atlas server
    A/B delivered
    Yerel connection state
    conn-h1 open
  8. Reuse için hazır

    Her iki self-delimited body tüketildi; explicit close yokken connection başka exchange taşıyabilir.

    Client / Duru
    Both complete
    Atlas server
    No pending response
    Yerel connection state
    conn-h1 reusable

HTTP/1.0 EOF

  1. Historical GET

    Historical branch yeni HTTP/1.0 connection’da yalnız bir GET ile başlar; persistence extension yoktur.

    Client / Duru
    GET /tea hazır; response bekleniyor
    Atlas server
    No request
    Yerel connection state
    conn-10 open
  2. GET ulaştı

    Server complete HTTP/1.0 request’i alır; body boundary için response tarafı ayrıca değerlendirilecektir.

    Client / Duru
    GET /tea hazır; response bekleniyor
    Atlas server
    GET /tea received
    Yerel connection state
    conn-10 open
  3. Close-delimited hazır

    Server Content-Length olmadan valid response hazırlar; body bitişini close belirleyecektir.

    Client / Duru
    Awaiting response
    Atlas server
    200 ready; no CL
    Yerel connection state
    conn-10 open
  4. Bytes ulaştı

    Status ve dört content byte client’a ulaştı; EOF olmadığı için message complete henüz false’dur.

    Client / Duru
    200; 4 bytes; incomplete
    Atlas server
    Response bytes delivered
    Yerel connection state
    conn-10 open
  5. Close event

    Örnekte verilen transport close, local connection state’ini kapatır. Bu olay logout veya yeni bir HTTP response değildir.

    Client / Duru
    200; 4 bytes; incomplete
    Atlas server
    Response bytes delivered
    Yerel connection state
    conn-10 closed; EOF
  6. EOF boundary

    Client EOF rule ile body bitişini belirler; text Çay tamamdır fakat aynı connection reuse edilemez.

    Client / Duru
    Complete: Çay
    Atlas server
    Exchange finished
    Yerel connection state
    conn-10 not reusable

ROLLER · STATE · VERİ AKIŞI

HTTP/1.0 tarihsel başlangıç noktası

Duru’nun Atlas client’ı bir not istediğinde HTTP/1.0 da method, target, status ve representation metadata taşır. RFC 1945 Mayıs 1996 tarihli Informational belgedir; bu derste historical behavior’ı açıklamak için kullanılır. Güncel parser ve HTTP/1.1 beklentisi o belgeden geriye doğru kurulmaz.

Belgenin normal operasyonu her request öncesinde connection açılması ve response sonrası kapatılmasıdır. HTTP/1.0 için sonradan görülmüş keep-alive extensions bu normal akışın aynısı değildir; bütün 1.0 clients’ın aynı persistence desteğine sahip olduğu varsayılamaz.

Tarihsel örnekte GET /tea için Content-Length bulunmayan bir 200 response vardır. Çay body’si dört UTF-8 byte’tır; fakat alıcı yalnız bu byte’ları görünce daha fazlasının gelmeyeceğini bilemez. Örnekte verilen connection close, response body’nin bitiş sınırıdır. Request body’yi close ile bitirmek aynı kural değildir; karşı yönün response gönderebilmesi gerekir.

Byte stream message boundary değildir

TCP application’a ordered bytes sunar; bir socket read bir HTTP message’a karşılık gelmek zorunda değildir. Tek read bir header’ın yarısını, bir message’ı veya iki message’ın birleşimini getirebilir. HTTP/1.1 parser start-line, CRLF-delimited fields, boş satır ve method/status context’inden framing’i belirler.

Normal fixture iki GET ve iki Content-Length response’u peş peşe koyar. İlk response Atlas note content’ini 10 byte, ikincisi Çay content’ini 4 byte olarak bildirir. Parser ilk header bölümünden sonra tam 10 content byte tüketir; bir sonraki response’un başlangıcı content değildir. Headers’ın okunur görünmesi bytes ölçümünü character count’a çevirmez.

Framing’de content olmayan HEAD/204 gibi context’ler, valid chunked message ve gerektiğinde close-delimited response ayrı kurallardır. Bu fixture yalnız normal GET + tek Content-Length kullanır. Current RFC, ambiguous completion’ı azaltmak için self-delimited responses’ı tercih eder; close-delimited bitiş transport failure ile normal bitişi ayırmayı zorlaştırabilir.

Persistence, completion’dan sonra reuse eder

HTTP/1.1 için persistent connection varsayılan olabilir. Normal branch tek conn-h1 üzerinde iki exchange taşır ve response’lar complete olduktan sonra connection açık kalır. Keep-Alive field’ı eklemek bu varsayılan davranışın önkoşulu değildir. Explicit close, peer policy veya transport event ise reuse’u bitirebilir.

Reuse için önceki message body’nin tüketilmesi önemlidir; önceki body bytes’ını yeni request/response’a karıştırmamak gerekir. Self-defined message length connection’ın açık kalmasıyla uyumludur. Response’un bitişini yalnız EOF’ye bağlayan fixture ise o connection’ı sonraki exchange için koruyamaz.

Connection açık kaldı diye application session aktif veya aynı subject doğrulanmış sayılmaz. Bu dersin conn-h1 alias’ı transport kaynağıdır, authentication record değildir. WEB-07.05’teki session/connection ayrımı burada message-level completion ve reuse’a bağlanır; policy sonuçları connection yönetiminden bağımsızdır.

Pipelining response sırasını kaldırmaz

Client birinci response’u beklemeden ikinci request’i gönderebilir: buna pipelining denir. İki request aynı byte stream’de sırayla alındığında server karşılık gelen response’ları aynı sırayla gönderir. Safe requests paralel işlenebilir; bu, response content’lerinin stream ID olmadan interleave edilebileceği anlamına gelmez.

Sahnede A=/atlas-notes önce, B=/tea sonra alınır. B’nin dört-byte response’u önce hazırdır; A’nın hazırlığı beklediği için B wire’a çıkamaz. A tamamlanınca önce A response’u, sonra B response’u ulaşır. B’nin hazır olması ile B’nin client’ta complete olması farklı state’lerdir; bu application-level head-of-line blocking’dir.

Burada iki safe GET vardır ve server scheduling delay yalnız supplied branch condition’dır; millisecond ölçümü yapılmaz. Gerçek clients pipelining kullanmak zorunda değildir. Retry kararı unanswered exchange, method semantics ve partial failure’a bağlıdır; beklemek veya connection kaybı non-idempotent action’ın çalışmadığını ispatlamaz.

2. Red · Güven ve etki

Hareket olmadan bütün senaryoları oku

Pipeline order

  1. Request sırası alias ile işaretlendi

    A, GET /atlas-notes; B, GET /tea request’ini adlandırır. Aynı HTTP/1.1 connection’da request order A, B’dir. Alias’lar öğretim için correlation sağlar; gerçek HTTP/1.1 stream identifier alanı değildir.

    Request/response ledger
    Requests: A, B
    Order/completion gate
    Completion gate bekliyor
    Application boundary
    Delivery sonucu bilinmiyor
  2. Hazırlık sırası delivery sırasından ayrıldı

    Server B response’unu A’dan önce hazırlayabilir; preparedOrder B, A’dır. Pipeline response sırası ise A, B kalır. B’nin hazır olması, A’nın önüne geçip client’a teslim edilebileceğini göstermez.

    Request/response ledger
    Requests: A, B
    Order/completion gate
    Prepared B,A / required delivery A,B
    Application boundary
    Delivery sonucu bilinmiyor
  3. Bekleme forbidden sonucuna çevrilmedi

    B’nin beklemesi bu ledger’da response ordering sonucudur. B için authorization deny gözlenmemiştir. İki safe GET’in aynı connection’da olması da iki resource’a permission vermez; application policy başka boundary’dedir.

    Request/response ledger
    Requests: A, B
    Order/completion gate
    Prepared B,A / required delivery A,B
    Application boundary
    B waits for order / permission unknown
  4. Bir socket read message sınırı sayılmadı

    Response stream, A ve B message’larını arka arkaya taşır. TCP read grupları bu message sınırlarını korumak zorunda değildir. A’nın Content-Length 10’u content sınırını belirler; sonraki bytes ayrı B message’ına ait olabilir.

    Request/response ledger
    A content 10 / next bytes may be B
    Order/completion gate
    Prepared B,A / required delivery A,B
    Application boundary
    B waits for order / permission unknown
  5. Parser completion ve bounded work ayrı tutuldu

    Maintained parser her message’ı framing koşuluyla tamamlar; read() dönüşünü complete HTTP response saymaz. Pending work ve timeout policy ayrıca sınırlanır. B’nin bekleme süresinin nedeni bu örnekte order’dır; production performans teşhisi yapılmaz.

    Request/response ledger
    A content 10 / next bytes may be B
    Order/completion gate
    Framing per message / bounded pending work
    Application boundary
    B waits for order / permission unknown
  6. Boundary sonucu hangi evidence’a ait olduğu ile verildi

    deliveredOrder A, B olarak verilmiştir; iki content tamamlanınca connection açık kalır. Bu kayıt transport/message scheduling’i açıklar. Gerçek browser pool, proxy, TLS veya business commit sonucu bu sıradan çıkarılmaz.

    Request/response ledger
    A content 10 / next bytes may be B
    Order/completion gate
    Framing per message / bounded pending work
    Application boundary
    Order A,B / connection open / app unknown

EOF boundary

  1. Historical response framing’i seçildi

    HTTP/1.0 branch’inde /tea response’u Content-Length veya Transfer-Encoding taşımaz. Çay body’si 4 byte’tır. Completion rule bu geçerli historical örnekte response connection close’dur; body metnini görmek tek başına boundary vermez.

    Request/response ledger
    H1.0 / CL absent / TE absent / body 4
    Order/completion gate
    Completion gate bekliyor
    Application boundary
    Delivery sonucu bilinmiyor
  2. Body bytes gelince completion erken verilmedi

    Dört byte mevcutken completeBeforeClose false’tur. Close-delimited framing daha fazla body byte gelmeyeceği bilgisini close event’inden alır. Application’ın text göstermeye başlaması bu HTTP message’ın tamamlandığını kanıtlamaz.

    Request/response ledger
    H1.0 / CL absent / TE absent / body 4
    Order/completion gate
    Before close: complete=false
    Application boundary
    Delivery sonucu bilinmiyor
  3. Incomplete state application failure sayılmadı

    Bu aşamada parser completion bekler. HTTP failure, authorization deny veya session logout kaydı eklenmez; bu mekanizmalar için ayrı evidence gerekir. Partial content ile final outcome aynı state değildir.

    Request/response ledger
    H1.0 / CL absent / TE absent / body 4
    Order/completion gate
    Before close: complete=false
    Application boundary
    Completion pending / application unknown
  4. Close event’in verilmiş niteliği korundu

    Historical ledger close event’i sağlar. Bu event native HTTP/1.0 socket ölçümü değildir. Event geldikten sonra parser’ın EOF boundary’si bilinir; model yeni network packet veya kullanıcı logout’u uydurmaz.

    Request/response ledger
    Supplied close / not a socket measurement
    Order/completion gate
    Before close: complete=false
    Application boundary
    Completion pending / application unknown
  5. Completion ve connection reuse farklı sonuçlandı

    completeAfterSuppliedClose true olur; reusableAfterClose false’tur. Body tamamlanmıştır ama aynı closed connection’da yeni exchange başlatılamaz. Self-delimited HTTP/1.1 branch’inin open sonucunu bu historical case’e kopyalamak yanlış olur.

    Request/response ledger
    Supplied close / not a socket measurement
    Order/completion gate
    After close: complete=true / reusable=false
    Application boundary
    Completion pending / application unknown
  6. Transport kapanışı session hükmü üretmedi

    Bu EOF, HTTP body boundary’sini belirler ve connection reuse’u bitirir. Business işlem, resource yaşamı veya session termination hakkında evidence sağlamaz. Aynı Çay text’ine ulaşmak bütün protocol branch’lerini eşdeğer yapmaz.

    Request/response ledger
    Supplied close / not a socket measurement
    Order/completion gate
    After close: complete=true / reusable=false
    Application boundary
    Message complete / session outcome unknown

VARSAYIM · SINIR · KONTROL

Yanlış sınır, yanlış exchange yorumuna dönüşür

Socket read’i complete message kabul eden bir application normal fragmentation veya coalescing sırasında bile yanlış sonuca ulaşabilir. Hata koşulu TCP delivery units ile HTTP framing’in eş tutulmasıdır; etki sonraki response’un yanlış resource’a eşlenmesine kadar uzanabilir.

Kontrol maintained protocol parser, version-aware completion ve bounded buffering kullanmaktır. Message length, received content length ve remaining bytes ayrı okunur. Burada iki valid normal response üzerinden bu ayrım görünür; parser’ın her input veya bütün deployments için güvenli olduğu sonucu çıkarılmaz.

Client’a content göstermeye başlanması business outcome’un kesinleştiğini veya response’un complete olduğunu tek başına bildirmez. Partial observation’ı final status/content ledger’ından ayırmak, güvenlik ve incident yorumunu aynı boundary üzerine kurar.

Queue ile authorization farklı kaynaklardır

Pipeline’da B bekliyorsa sebep burada A response sırasıdır; “B forbidden” değildir. Connection ve pending responses kaynak tüketir, fakat her gecikme saldırı sayılmaz. Slow upstream, application work veya normal scheduling aynı görünen wait state’i yaratabilir.

Savunma bounded pending work, timeout/reuse policy ve resource authorization’ı ayrı değerlendirmektir. Yeni connection açmak response-order sorununu bazı durumlarda azaltabilir ama sınırsız connection genel çözüm değildir; server ve network kaynakları paylaşılır.

Duru’nun iki GET’i aynı connection’dan gelmesi iki resource’a otomatik permission vermez. Method’ün safe olması access-control sonucu değildir. Bu fixture yalnız transport/message scheduling’i öğretir; subject ve resource policy gerçek application boundary’sinde uygulanır.

3. Blue · Güvenli geliştirme ve savunma

Hareket olmadan bütün senaryoları oku

Message ledger

  1. Content count tam message count’tan ayrıldı

    A’nın Atlas note content’i 10 byte, bütün response message’ı 127 byte’tır. B’nin Çay content’i 4 byte, bütün message’ı 120 byte’tır. Headers ve delimiter overhead’i Content-Length’e eklemek yanlış karşılaştırma olur.

    Message record
    A: 10/127 bytes / B: 4/120 bytes
    Correlation review
    Count/order review bekliyor
    Evidence conclusion
    Coverage verdict yok
  2. UTF-8 hesabı message sınırını korudu

    Çay üç code point fakat dört UTF-8 byte taşır. B’nin Content-Length 4’ü bu content ile eşleşir. String karakter sayısını octet sayısı yerine kullanmak A/B correlation’ında boundary’yi yanlış yerde sonlandırır.

    Message record
    A: 10/127 bytes / B: 4/120 bytes
    Correlation review
    A CL 10 / B CL 4 consistent
    Evidence conclusion
    Coverage verdict yok
  3. Hazırlık ve arrival arrays ayrı okundu

    preparedOrder B, A iken deliveredOrder A, B’dir. B-ready observation, B-arrived observation değildir. Aynı request order’a bağlanan bu iki ölçü ayrı tutulursa normal pipeline beklemesi yanlış response sırası sanılmaz.

    Message record
    Prepared B,A / delivered A,B
    Correlation review
    A CL 10 / B CL 4 consistent
    Evidence conclusion
    Coverage verdict yok
  4. Order oracle normal ve positive control ile sınandı

    Normal selector XML’i requestOrder A,B ve deliveredOrder A,B verir; mismatch count sıfırdır. Positive XML deliveredOrder B,A bildirir ve count bir olur. Positive control authored observation’dır, gerçek protocol failure kaydı değildir.

    Message record
    Prepared B,A / delivered A,B
    Correlation review
    Normal mismatch 0 / positive mismatch 1
    Evidence conclusion
    Coverage verdict yok
  5. Normal tamamlanma session olayı sayılmadı

    İki self-delimited response tamamlanınca connectionAfterComplete open kalır. Bu connection reuse koşuludur. Login, logout, user role veya private resource policy hakkında bir event bu message ledger’da yoktur.

    Message record
    Prepared B,A / delivered A,B
    Correlation review
    Normal mismatch 0 / positive mismatch 1
    Evidence conclusion
    Messages complete / connection open
  6. Regression byte ve sıra koşuluna bağlandı

    Server hazırlık kaydı preparedOrder=B,A sonucunu, client HTTP parser’ı ise aynı connection’daki request sırasına bağlı deliveredOrder=A,B ve complete message sınırlarını sağlayabilir. A/B gerçek stream ID değildir. Header serialization değişirse 127 ve 120 message byte sayısı yeniden hesaplanır.

    Message record
    Prepared B,A / delivered A,B
    Correlation review
    Normal mismatch 0 / positive mismatch 1
    Evidence conclusion
    Recheck content bytes, message bytes and order

Arrival gap

  1. Review için observation kapsamı belirlendi

    Alternatif review’de request order A,B ve server hazırlık sırası bilinir, fakat client delivery observation’ı yoktur. Normal artifact deliveredOrder içerir; o değer eksik bir trace’in kendi evidence’ı gibi kullanılamaz.

    Message record
    Request/preparation known / arrival unobserved
    Correlation review
    Count/order review bekliyor
    Evidence conclusion
    Coverage verdict yok
  2. Hazırlık kaydı arrival boşluğunu kapatmadı

    B’nin önce hazır olması client’a önce ulaştığını söylemez. A’nın hazır kaydı da client receipt’i değildir. Correlation gate, observer konumunu ve complete message boundary’sini sorgular; server-side state’i client-side ölçüm yerine geçirmez.

    Message record
    Request/preparation known / arrival unobserved
    Correlation review
    Ready ≠ arrival / receiver coverage needed
    Evidence conclusion
    Coverage verdict yok
  3. Missing trace zero match üretebilir

    Order selector’ı yalnız mevcut pipeline observation’larını seçer. Delivered order kaydı yoksa tutarsızlık sayısı sıfır kalabilir. Bu sonuç trace’in tam olduğunu veya protocol sırasının korunduğunu kanıtlamaz.

    Message record
    Zero mismatch possible with missing evidence
    Correlation review
    Ready ≠ arrival / receiver coverage needed
    Evidence conclusion
    Coverage verdict yok
  4. Negative control scope’a göre değerlendirildi

    Normal tam XML ile positive mismatch XML birlikte oracle davranışını sınar. Eksik client observation ise bu iki control’den başka bir durumdur. Test fixture’ın verdiği beklenen array’i eksik observation yerine geçirmek coverage şartını kaldırır.

    Message record
    Zero mismatch possible with missing evidence
    Correlation review
    Controls known / actual arrival evidence absent
    Evidence conclusion
    Coverage verdict yok
  5. Delivery verdict unknown olarak bırakıldı

    Bu review’de delivery order UNKNOWN kalır. Network loss, authorization deny veya session termination sonucu eklenmez. Kanıt eksikliği, bir boundary’nin başarısız olduğunu da başarılı olduğunu da tek başına göstermez.

    Message record
    Zero mismatch possible with missing evidence
    Correlation review
    Controls known / actual arrival evidence absent
    Evidence conclusion
    UNKNOWN: client delivery order
  6. Yeni observation minimum scope ile istendi

    Hükmün değişmesi için client observer’ın message completion ve correlation kaydı gerekir. Bütün private content’i saklamak zorunlu değildir; request order, declared length, completion ve observer scope yeterli olabilir. Gerçek yeni evidence gelmeden normal fixture’ın sonucu aktarılmaz.

    Message record
    Zero mismatch possible with missing evidence
    Correlation review
    Controls known / actual arrival evidence absent
    Evidence conclusion
    Needed: receiver completion + correlation

UYGULAMA · GÜVENLİK KONTROLÜ · DOĞRULAMA

Sırayı ve tamamlanmayı aynı ledger’da tut

Manual exercise’de her request’e öğretim için A/B sıra alias’ı ver, response’ların content bytes’ını declared length ile say. Alias gerçek HTTP/1.1 stream identifier değildir; request order üzerinden correlation yapılır. Her response’un son byte’ından sonra başlayan alanı bir sonraki message olarak işaretle.

B-ready observation A-ready’den önce olabilir, buna karşın B-arrived A-arrived’den sonra olmalıdır. Artifact bu iki sıra için ayrı arrays kullanır. XPath ikinci response’un önce teslim edilmiş olduğunu söyleyen authored observation’ı seçer; normal 0, inconsistent pozitif fixture 1 verir.

Missing observation da 0 dönebilir; bu pipeline sıra kontrolü doğrulandı anlamına gelmez. Complete trace scope, correlation ve message completeness olmadan “hızlı/başarılı” yorumunu ertele. Diagnostic veri için tüm body veya kişisel notları saklamak gerekmeyebilir.

Close event’i framing bağlamında oku

Historical branch’te dört content byte gelince response henüz EOF-delimited olarak bitmiş değildir. Supplied close event sonrasında parser body boundary’sini bilir; connection reuse artık yoktur. Close event’i application logout veya resource silinmesi gibi çizmek farklı bir mekanizmayı uydurur.

Current self-delimited branch’te CL=10 ve CL=4 tamamlanır, connection açık kalır. İki branch aynı görünen text’i verse de completion rule ve reuse sonucu aynı değildir. Manuel inceleme önce version/method/status, sonra framing, sonra transport kapanışı sırasını izler.

Yerel native fixture iki safe GET’in sıraya bağlı response teslimini ölçebilir; authored sahnenin tamamı canlı capture sayılmaz. Gerçek Browser pool davranışı, TLS, proxy conversion, production timeout ve session policy kendi ayrı kanıtlarını gerektirir.

Persistent HTTP/1.1 kullanan implementation, response body’sinin tamamını okumadan aynı connection’ı yeni request için reuse etmemelidir. Server tarafı da request body’sini bütünüyle tüketmeli veya response sonrası connection’ı kapatmalıdır. Framing’i standard HTTP implementation’a bırak; application’ın bir read chunk’ını bütün mesaj sanmasına izin verme. Bu iki normal GET’te B hazır olsa bile A’dan önce response olarak çıkmaması ve her body sınırının tamamlanması, ayrı fakat birlikte korunması gereken koşullardır.

ŞİMDİ VAKAYA UYGULA

Hazırlık, message completion ve client arrival hangi ayrı kanıtları ister?

A, Atlas note; B, Çay response’unu adlandırır. Server B’yi önce hazırlasa da HTTP/1.1 pipeline response sırası A, B kalır. Historical HTTP/1.0 örneğinde ise dört body byte yetmez; close event’i completion sınırını verir.

Vakadaki response başka bir HTTP transport üzerinde gelseydi hangi application koşulları yine gerekli olurdu? Stream veya packet completion’ını başarılı note parsing’le eşitleme.

Bağlı vaka dosyasını aç ↗

ÖRNEĞİ BİRLİKTE OKUYALIM

A/B pipeline ve EOF ledger

Bir alan seç; hangi sonucu desteklediğini ve nerede yetersiz kaldığını incele.

Ham kaydı ve alan açıklamalarını oku
{
  "requests": [
    {
      "alias": "A",
      "path": "/atlas-notes",
      "wire": "GET /atlas-notes HTTP/1.1\r\nHost: library.atlas.example\r\n\r\n"
    },
    {
      "alias": "B",
      "path": "/tea",
      "wire": "GET /tea HTTP/1.1\r\nHost: library.atlas.example\r\n\r\n"
    }
  ],
  "responses": [
    {
      "alias": "A",
      "body": "Atlas note",
      "contentOctets": 10,
      "wire": "HTTP/1.1 200 OK\r\nDate: Thu, 08 Oct 2026 00:00:00 GMT\r\nContent-Type: text/plain; charset=utf-8\r\nContent-Length: 10\r\n\r\nAtlas note",
      "messageOctets": 127
    },
    {
      "alias": "B",
      "body": "Çay",
      "contentOctets": 4,
      "wire": "HTTP/1.1 200 OK\r\nDate: Thu, 08 Oct 2026 00:00:00 GMT\r\nContent-Type: text/plain; charset=utf-8\r\nContent-Length: 4\r\n\r\nÇay",
      "messageOctets": 120
    }
  ],
  "requestStream": "GET /atlas-notes HTTP/1.1\r\nHost: library.atlas.example\r\n\r\nGET /tea HTTP/1.1\r\nHost: library.atlas.example\r\n\r\n",
  "responseStream": "HTTP/1.1 200 OK\r\nDate: Thu, 08 Oct 2026 00:00:00 GMT\r\nContent-Type: text/plain; charset=utf-8\r\nContent-Length: 10\r\n\r\nAtlas noteHTTP/1.1 200 OK\r\nDate: Thu, 08 Oct 2026 00:00:00 GMT\r\nContent-Type: text/plain; charset=utf-8\r\nContent-Length: 4\r\n\r\nÇay",
  "preparedOrder": [
    "B",
    "A"
  ],
  "deliveredOrder": [
    "A",
    "B"
  ],
  "connectionAfterComplete": "open",
  "http10": {
    "request": "GET /tea HTTP/1.0\r\n\r\n",
    "responseBytesBeforeClose": "HTTP/1.0 200 OK\r\nDate: Thu, 08 Oct 2026 00:00:00 GMT\r\nContent-Type: text/plain; charset=utf-8\r\n\r\nÇay",
    "body": "Çay",
    "bodyOctets": 4,
    "contentLengthField": null,
    "transferEncodingField": null,
    "completionRule": "response connection close",
    "completeBeforeClose": false,
    "completeAfterSuppliedClose": true,
    "reusableAfterClose": false,
    "scope": "Historical valid close-delimited response; EOF event supplied, not a native HTTP1.0 measurement."
  },
  "selector": {
    "language": "XPath",
    "xml": "<observations><pipeline requestOrder=\"A,B\" deliveredOrder=\"A,B\"/></observations>",
    "xpath": "count(/observations/pipeline[@requestOrder=\"A,B\" and @deliveredOrder!=\"A,B\"])",
    "expected": 0,
    "positiveFixtureXml": "<observations><pipeline requestOrder=\"A,B\" deliveredOrder=\"B,A\"/></observations>",
    "positiveExpected": 1,
    "scope": "Only authored protocol-decision observations, not product log field names or a live HTTP capture.",
    "missingFieldBehavior": "Missing observation is insufficient evidence; zero matches is not proof of correct runtime behavior."
  }
}
preparedOrder / deliveredOrder
Server hazırlık sırası ve client arrival sırası farklı ölçülerdir.
contentOctets / messageOctets
Content-Length yalnız content’i sayar; bütün message ayrıca headers içerir.
http10.completeBeforeClose
EOF-delimited response’un supplied close öncesi completion false.

Valid safe GET fixtures; A/B gerçek protocol fields değildir. Historical close supplied; native yerel pipeline kanıtı ayrı kapsamda tutulur. Browser/TLS/proxy/session ölçümü değildir.

İki yanlış kanı

Pipelining ikinci response’u hazır olduğunda birincinin arasına sokar.

HTTP/1.1 response order request order’ı izler. B hazır olsa da A response’u tamamlanana kadar bekler; streams ile multiplexing farklıdır.

TCP read bittiğinde HTTP message bitmiştir.

Socket delivery sınırı message sınırı değildir. Self-delimited length veya doğru EOF context’i framing’i belirler; dört byte alınması tek başına bitişi ispatlamaz.

SIRA SENDE

Bu hikâyeyi sen çöz.

Sonucu tahmin et, kanıtın sınırını bul ve nedenini kendi cümlenle anlat.

Pipeline’da A sonra B alındı; B response önce hazır. HTTP/1.1 delivery sırası nedir?

  1. A, B. Hazır B response ilk response’u bekler.
  2. B, A. Biten handler her zaman önce wire’a yazılır.
Gerekçeli cevabı oku

A, B. Hazır B response ilk response’u bekler. — Pipelined response’lar request sırasıyla eşlenir. preparedOrder=[B, A], delivery sırasını değiştirmez.

Bu HTTP/1.0 close-delimited response ne zaman complete sayılır?

Dersten seçilen artifact alanları; öğretim örneği

http10.contentLengthField
null
http10.completeBeforeClose
false
http10.completeAfterSuppliedClose
true
  1. Çay metni görünür görünmez; body uzunluğu tahmin edilir.
  2. Connection close ile EOF geldikten sonra.
Gerekçeli cevabı oku

Connection close ile EOF geldikten sonra. — Close-delimited content’in sonu EOF ile bilinir. O connection sonrasında reusable değildir.

HTTP/1.1 aynı byte stream’de iki Content-Length response’u nasıl ayırır? Read çağrısının sınırı neden yeterli değil?

Gerekçeli cevabı oku

Parser CRLF header sınırını bulur; ilk response’un 10 content octet’ini tüketir. Ardından ikinci start-line/header ve 4 octet content gelir. TCP read parçaları message sınırlarıyla örtüşmek zorunda değildir. Body’den sonra keyfi boşluk aramak bu örnekteki length framing kuralı değildir.

□ Content octet sayısını framing için kullandım.

□ TCP read sınırını HTTP message sınırı saymadım.

Uygulama konsolunu aç · request / response / browser
Request, URL, cookie ve DOM örneklerini ayrıca aç

Kaynaklar ve kapsam