HTTP Protocol and Web Fundamentals Questions

Approach: treat each pushed resource as a synthetic server-initiated stream that must obey both the stream-level and connection-level flow-control windows. Maintain per-stream and global send queues, only emit DATA frames when both windows permit. Use prioritization and soft quotas so slow clients don’t block unrelated active streams.

Algorithm (explanatory + simplified Python-like pseudocode):

# Simplified structures
connection_window = N  # connection-level bytes allowed
streams = {stream_id: Stream(window, priority, send_queue)}

def try_send():
    # Choose streams by priority but enforce fairness
    for s in select_streams_by_priority_and_fairness(streams):
        while s.send_queue and connection_window > 0 and s.window > 0:
            chunk = s.send_queue.peek_chunk(max_bytes=min(s.window, connection_window, MAX_FRAME))
            send_data_frame(s.id, chunk)
            bytes_sent = len(chunk)
            s.window -= bytes_sent
            connection_window -= bytes_sent
            s.send_queue.pop_chunk(bytes_sent)
        if s.send_queue and (s.window==0 or connection_window==0):
            mark_blocked(s)

Key points / reasoning:

• Window accounting: decrement both s.window and connection_window when sending; restore on RECEIVED WINDOW_UPDATE frames. Pushed resources consume the same global connection window as other streams.
• Avoid stalling: implement a scheduler that uses weighted fair queuing or deficit round-robin across streams and pushed-streams so a slow consumer (small stream window) only holds its share. Give higher priority to user-initiated streams; cap bytes used by server-push per connection (push_quota) to prevent exhaustion.
• Backpressure handling: when a push is blocked for long, stop sending and either queue on server for a TTL, shrink push_quota, or send RST_STREAM for that pushed stream. Expose metrics (blocked_pushes, connection_window_pressure) and alert when thresholds pass.
• Safety: ensure push promises respect client SETTINGS (ENABLE_PUSH) and limit concurrent pushed streams to avoid resource exhaustion.

Trade-offs:

• Strict fairness adds scheduler complexity but prevents head-of-line blocking.
• Aggressive push_quota prevents push abuse at cost of potential missed preloads.

Likely causes (framing / chunked-related)

• Missing/incorrect Content-Length or Transfer-Encoding headers so the client/server don’t agree on response boundary — server writes body but doesn’t signal end, next response bytes are treated as continuation.
• Incorrect implementation of chunked encoding: wrong chunk size lines, missing final 0\r\n\r\n, or forgetting CRLF between chunks.
• Mixing buffered and unbuffered I/O or shared buffers across connections/threads leading to interleaved writes on the same socket.
• HTTP parser/reader logic not keeping a strict request/response loop: reading more bytes into the next request or not draining request body before writing response, especially with pipelining.
• Keep-Alive + non-reentrant handlers: handler reuses state across requests on same connection.

Fixes

• Ensure deterministic framing:
  • Always send either a correct Content-Length header or well-formed Transfer-Encoding: chunked (include chunk-size CRLF data CRLF, final 0\r\n\r\n).
  • If using chunked, send the terminating 0\r\n\r\n reliably even on errors.
• Make request/response lifecycle strict:
  • Read full request (including body) before writing response.
  • Serialize writes per-connection; avoid global buffers. Use per-connection locks if multiple threads may write.
• Use battle-tested libraries (asyncio streams, h11, httptools, or Python’s http.server) rather than hand-rolled parsers.
• Optionally disable pipelining (send Connection: close or reject pipelined requests) if server cannot safely support it.
• Add instrumentation (bytes written, chunk counts, unexpected EOFs) and enable debug logs for framing.

Tests to add (regression + CI)

1. Integration pipelining test: open a single TCP connection, send two or more valid requests back-to-back (without waiting), assert each response is exactly the intended body and headers, and that boundaries are respected.
2. Chunked encoding correctness: send requests that trigger chunked responses; assert chunk sizes, CRLFs, and final 0 chunk present and responses parse correctly.
3. Interleaving/concurrency test: multiple clients sending pipelined requests concurrently to same backend worker to surface shared-state races.
4. Fuzz / property tests: randomize chunk sizes, include aborted connections, partial writes to ensure server always terminates chunked responses and doesn’t splice responses.
5. End-to-end test with real HTTP parsers/clients (curl --http1.1 --no-buffer) to exercise real-world clients.

Example pytest integration test (basic)

import socket

def test_pipelined_responses():
    s = socket.create_connection(('localhost', 8080))
    req = ("GET /a HTTP/1.1\r\nHost: local\r\nConnection: keep-alive\r\n\r\n"
           "GET /b HTTP/1.1\r\nHost: local\r\nConnection: close\r\n\r\n")
    s.sendall(req.encode())

    data = b''
    while b'Content-Length' not in data:
        data += s.recv(4096)
    # naive split: ensure two distinct responses present and not concatenated bodies
    assert b'HTTP/1.1 200' in data
    assert data.count(b'HTTP/1.1 200') == 2
    # further parse Content-Length headers and verify exact body lengths...
    s.close()

Monitoring & alerts

• Add alerts for unexpected long-lived connections, unusually high bytes-per-connection, or increased parsing errors.
• Log framing errors with connection id + hex dump for post-incident debugging.

This combination of deterministic framing, using robust parsers, per-connection write isolation, and targeted tests will prevent concatenated responses from pipelined requests.

High-level TLS handshake (simplified):

• ClientHello: client sends supported TLS version, cipher suites, extensions (SNI, ALPN), and a random nonce.
• ServerHello: server picks TLS version/cipher suite, returns its random nonce and chosen params.
• Certificate verification: server sends its certificate chain; client validates chain, hostname (via SNI), and trust root/CRL/OCSP stapling.
• Key exchange: using chosen cipher (e.g., ECDHE) both sides derive shared secret from nonces + ephemeral key material; resulting session keys encrypt traffic. Handshake finishes with Finished messages to verify integrity.
• Session resumption: client uses session ID or session ticket to skip full handshake, enabling faster reconnects with reduced CPU/latency.

SRE operational considerations — TLS termination at the edge (load balancer/CDN) vs pass-through to origin:

• Performance & latency: edge termination offloads CPU-heavy crypto from origin, reduces origin latency; but double-encryption (edge→origin TLS) adds CPU cost if re-encrypting.
• Security: terminating at edge lets you inspect/apply WAF, DDoS mitigation, and TLS policy centrally; pass-through preserves end-to-end encryption and limits surface area for plaintext.
• Certificate management: edge termination centralizes cert lifecycle (renewal, automation, ACME). Pass-through requires certs on each origin or TLS passthrough-aware cert provisioning.
• Observability & debugging: edge termination enables TLS-level metrics (client cipher, SNI, handshake failures) and logging; pass-through limits visibility unless you instrument at origin or use TLS observability tools.
• Compliance & data residency: some regulations require end-to-end encryption—pass-through may be needed.
• Scaling & capacity planning: ensure edge has crypto capacity, hardware acceleration (AES-NI, TLS offload), or autoscale; monitor handshake rates, session cache sizes, and ticket rotation.
• Operational complexity: edge termination simplifies origin configs but centralizes policy; pass-through reduces central control but increases origin maintenance.
• Availability: certificate/key compromise risk concentrated at edge—use HSMs or limited key exposure, and design key rotation and failover procedures.
  Recommendations:
• Terminate at edge for performance, WAF, and simplified cert ops unless policy/compliance requires end-to-end encryption. If terminating, consider re-encrypting to origin, use OCSP stapling, enable TLS 1.3, session tickets, hardware acceleration, fine-grained metrics, and automated cert management (ACME/HSM).