Force all requests through one ServerPipe with Fiddler

Question

I'm trying to route matching domain requests through a single ServerPipe, but I cant figure out how to get fiddler to reuse that ServerPipe for all ClientPipes

Normal behaviour of a chromium based browser is to open up to 6 connections to a server for a given domain (when there are multiple resources to get). When proxying through fiddler, this normally results in up to 6 ServerPipes. I want to permit the first to establish a server connection, skip connecting the next 5 and then have all client requests use the first server connection. From the browsers point of view it will still have 6 client connections to fiddler.

Here is where I'm at -

1. Let the first CONNECT request pass as normal, which establishes the first connection to the server
2. When the next 5 client CONNECT's come in, set the x-ReplyWithTunnel flag on the session in the BeforeRequest handler. This will bypass creating a new server connection, but respond to the client as though a server connection was successfully established
3. The client sends a bunch of GET requests down the 6 client pipes to fiddler requesting the resources from the server. Those in the first pipe (with the actual server pipe) complete.
4. Those GET requests in the other 5 tunnels present to fiddler, but no response is processed and sent back to the client.

I've tried all manner of ideas but cannot get fiddler to reuse the single server connection for all 6 client pipes. All GET requests are to the same domain, so ServerPipe reuse should be ok, no?

Is this even possible ?

If yes, what am I missing ?

Answer 1

Finally worked it out after significant effort.

Under the hood Fiddler uses a "pool" of Pipes to each server. In my initial post, I was only allowing the creation of a single connection per domain. When the first GET rolled in for a domain, that session takes the only Pipe out of the pool for its use. When the other 5 GET's arrive, they cant find any Pipes in the pool and subsequently fail.

To work around the problem, one needs to throttle the subsequent GET's and only allow them to run one at a time, once each prior GET is complete.

When this orderly process occurs the Pipe will be put back in the pool, and the next GET in the queue will successfully locate a Pipe to use. Unicorns and rainbows then appear.

I used a SemaphoreSlim to "queue" the threads in the BeforeRequest and a .Set() in the BeforeResponse per domain. The basic functionality works for my needs, but a full implementation would require dealing with things like failed Pipes, hanging GET's and flag overrides.