HTTP/2: peer MAX_CONCURRENT_STREAMS=0 leaves stale capacity and a LocalProtocolError

[adenzhou1350]

I reproduced a zero-limit edge case on current master (10a658221deb38a4c5b16db55ab554b0bf731707) before proposing a fix.

A loopback hyper-h2 server advertises 10 concurrent streams, sends a response, then advertises 0 before ending that response. The first request finishes normally. A second public AsyncConnectionPool.request() raises:

httpcore.LocalProtocolError: Max outbound streams is 0, 0 open

The same test with the update set to 50 completes both requests. The zero-limit peer observes only stream 1: h2 correctly rejects the extra stream locally; this is not a claim that httpcore sends invalid frames.

In _receive_remote_settings_change, if new_max_streams ignores zero. h2 records 0 while httpcore's _max_streams remains 10. RFC 9113 §6.5.2 permits zero as a temporary limit; §5.1.2 allows existing streams to complete after a decrease.

Simply changing that guard to is not None is unsafe: using the existing MockStream-style test, both asyncio and Trio block while processing the zero update before the response's final body frame. The shrink loop tries to acquire the permit still held by the response being read. This was an independent predicate-only diagnostic, not a proposed patch.

What behavior would you prefer here: waiting for a later SETTINGS increase, or another pool-level handling strategy? A repair needs to preserve existing-response progress, cancellation and later 0→positive updates, rather than only removing the truthiness check. I checked related #1037 / #1035; they discuss connection capacity selection, but I did not find this exact zero-update reproduction in them. Please point me to existing work if I missed it.

Tested on Linux/Python 3.12.13, AnyIO 4.15.1, h2 4.4.1, h11 0.16.0, hpack 4.2.0 and hyperframe 6.1.0. The real TCP check is asyncio with HTTP/2 prior knowledge, not TLS or a claim about prevalence in deployed servers. AI-assisted investigation; the full-package reproductions and the counterexample above were executed independently.

Self-contained loopback TCP reproduction (no external server)

import asyncio
import json
import h2.config
import h2.connection
import h2.events
import h2.settings
import httpcore

async def trial(limit):
    observed=[]
    tasks=set()
    async def handle(reader,writer):
        task=asyncio.current_task()
        tasks.add(task)
        connection=h2.connection.H2Connection(config=h2.config.H2Configuration(client_side=False))
        connection.initiate_connection()
        connection.update_settings({h2.settings.SettingCodes.MAX_CONCURRENT_STREAMS:10})
        writer.write(connection.data_to_send())
        await writer.drain()
        try:
            while data:=await reader.read(65536):
                for event in connection.receive_data(data):
                    if isinstance(event,h2.events.RequestReceived):
                        observed.append(event.stream_id)
                        connection.send_headers(event.stream_id,[(b':status',b'200')])
                        connection.send_data(event.stream_id,b'first')
                        connection.update_settings({h2.settings.SettingCodes.MAX_CONCURRENT_STREAMS:limit})
                        connection.send_data(event.stream_id,b'last',end_stream=True)
                writer.write(connection.data_to_send())
                await writer.drain()
        finally:
            writer.close()
            await writer.wait_closed()
            tasks.remove(task)
    server=await asyncio.start_server(handle,'127.0.0.1',0)
    port=server.sockets[0].getsockname()[1]
    error=None
    statuses=[]
    async with server:
        async with httpcore.AsyncConnectionPool(http1=False,http2=True,max_connections=1) as pool:
            for index in range(2):
                try:
                    response=await asyncio.wait_for(pool.request('GET',f'http://127.0.0.1:{port}/'),2)
                    statuses.append({'status':response.status,'body':response.content.decode()})
                except Exception as exc:
                    error=type(exc).__name__+': '+str(exc)
                    break
            pool_state=repr(pool)
        server.close()
        await server.wait_closed()
        if tasks:
            await asyncio.wait_for(asyncio.gather(*tuple(tasks)),2)
    return dict(limit=limit,responses=statuses,error=error,peer_request_stream_ids=observed,pool_state=pool_state)



async def main():
    normal = await trial(50)
    zero = await trial(0)
    assert len(normal["responses"]) == 2 and normal["error"] is None
    assert zero["error"] == "LocalProtocolError: Max outbound streams is 0, 0 open"
    assert zero["peer_request_stream_ids"] == [1]
    print(json.dumps([normal, zero], indent=2))

asyncio.run(main())

[adenzhou1350]

Follow-up: this also reproduces with a positive limit on unchanged master 10a658221deb38a4c5b16db55ab554b0bf731707, not just the proposed zero-limit guard change.

Using a real loopback hyper-h2 server and public AsyncConnectionPool.stream() calls, with the pool configured as http1=False, http2=True, max_connections=1:

1. The peer advertises 10. Start two requests on the same connection (stream IDs 1 and 3), leaving their bodies open.
2. After receiving the second request, the peer lowers the limit to 1, then sends final DATA + END_STREAM for both streams.
3. Both client requests remain pending at the two-second observation, until the probe cancels its own tasks. Changing only the new limit to 2 makes both responses finish normally.

I repeated each case three times on Linux/Python 3.12 and Windows/Python 3.12 and 3.14: all nine limit-2 controls finished, and both requests stayed pending in all nine limit-1 cases. Linux used AnyIO 4.15.1 / h2 4.4.1; Windows used AnyIO 4.11.0 / h2 4.3.0. All 32 HTTPcore package files matched the pinned commit's Git blobs; no socket/transport mocks or source changes.

This is consistent with the shrink loop acquiring permits under _read_lock before later response events are queued; those responses must close to release the permits. RFC 9113 §5.1.2 allows a peer to lower the limit below its active stream count and let existing streams finish.

A repair therefore needs to preserve active-response progress for positive decreases below the active count too. This adds an asyncio TCP regression case, not a validated fix or a TLS/Trio/sync/full-CI claim.