NEWS (4535B)
1 Unreleased: 2 - Payment confirmation retries an order-status GET once when the merchant 3 connection fails before returning any HTTP response. The retry stays 4 within the original five-second deadline, preventing a stale pooled 5 connection from intermittently turning a completed payment into error 6 9801. Merchant-related error JSON now includes `merchant_http_status', 7 with zero meaning that no HTTP response was received. When both attempts 8 fail early, the sampled warning queues one bounded, forced-fresh request 9 for the same order and logs its addresses, HTTP result, OS errno, 10 connection count and DNS/TCP/TLS/first-byte timings. This distinguishes a 11 shared connection-pool failure from general backend reachability without 12 logging the bearer token or response body. 13 14 - MERCHANT_BACKEND_INTERNAL_URL may now select a private HTTP(S) route for 15 Paivana's merchant API calls while MERCHANT_BACKEND_URL remains the public 16 URL advertised to browsers and wallets. In particular, a public HTTPS 17 merchant can be reached through a cleartext MERCHANT_BACKEND_UNIX_PATH 18 without attempting TLS over that socket or exposing an internal URL in the 19 paywall. 20 21 - High-load operation is now fail-fast and bounded. CONNECTION_LIMIT 22 defaults to 384 and may not exceed the select()-safe descriptor budget; 23 PAYMENT_CONNECTION_LIMIT reserves 32 request slots for redemptions, and 24 RELAY_MEMORY_LIMIT validates aggregate streaming-ring memory. Unsafe 25 descriptor, RLIMIT_NOFILE and memory combinations are startup errors. 26 27 - SIGTERM quiesces listeners and drains accepted requests for 28 SHUTDOWN_GRACE_PERIOD (60 s by default). Template discovery, concurrent 29 detail fetches, retained Paivana templates, contract size, installed 30 languages and the process-wide rendered-response cache now have documented 31 bounds. Repeated merchant transport diagnostics are sampled once per 32 minute per failure class with a recovery summary. 33 34 - The reverse proxy streams both directions. A request or response 35 body is relayed as it arrives instead of being assembled in memory 36 first, so its size is no longer bounded by memory -- previously 37 anything over 40 MiB was refused outright with 502, and the client 38 could not receive a single byte until the origin had sent the last 39 one. The origin's framing now reaches the client unchanged as 40 well: a declared Content-Length stays declared and a chunked 41 response stays chunked, where before both were recomputed from the 42 assembled buffer. A HEAD accordingly reports the length the 43 equivalent GET would have had, rather than 0. 44 45 - Configuration: REQUEST_BUFFER_MAX (and its -u/--max-upload flag) 46 now sizes the buffer a request body is relayed through, 256 KiB by 47 default, and no longer decides how large an upload may be. That is 48 MAX_REQUEST_SIZE, new, 1 MiB by default. RESPONSE_BUFFER_MAX is 49 the mirror of the first; there is deliberately no mirror of the 50 second, since removing the limit on a response is the point of the 51 change. 52 53 UPGRADING: a configuration that set REQUEST_BUFFER_MAX (or -u) to 54 permit large uploads meant the limit, so where it is set and 55 MAX_REQUEST_SIZE is not, MAX_REQUEST_SIZE takes its value. Such a 56 configuration therefore keeps behaving as it did, at the cost of a 57 correspondingly large relay buffer; set both explicitly to separate 58 them. 59 60 - Timeouts: UPSTREAM_TIMEOUT (60 s) now bounds the time to the 61 response *headers* rather than to the whole transfer, since a large 62 download legitimately runs for longer than any useful ceiling. A 63 stalled transfer is bounded instead by the new 64 UPSTREAM_STALL_TIMEOUT (60 s), which is how long the origin may 65 move no bytes in either direction, and which does not run while 66 paivana is holding the origin back because the client has not 67 caught up. 68 69 - An origin that fails after its response headers have gone out can 70 no longer be reported as 502: the status is already on the wire. 71 It is reported as a framing error instead -- a declared 72 Content-Length that is not met, or a chunked response closed 73 without its terminating chunk -- which RFC 9112 section 8.1.2 74 requires a client to treat as a failure. The exception is an 75 HTTP/1.0 client receiving a response of unknown length, where the 76 close is the framing and truncation cannot be signalled. 77 78 - Requires GNUnet 0.29.0 for GNUNET_CURL_job_add_stream().