Canceling a HTTP request while it is reading a partial cache entry does not cancel the corresponding transaction. When a HTTP range request is used to complete a partial cache entry, we first issue a range request and if we get back a 206, then we read the cache and send the partial cache data to our listener. If the listener cancels the channel by returning an error code (e.g., NS_BINDING_ABORTED) from their OnDataAvailable, then the network transaction will never be closed. It will just sit around, consuming a persistent connection. If this process is repeated, then subsequent requests to the same host may get stuck waiting for an available persistent connection.
Status: NEW → ASSIGNED
Priority: -- → P1
Target Milestone: --- → mozilla1.8beta3
Actually, this bug appears to affect the 1.7 branch only. The transaction is somehow getting closed properly on the trunk.
Version: Trunk → 1.7 Branch
I take that back. This can be reproduced on the trunk as well.
Version: 1.7 Branch → Trunk
Created attachment 188717 [details] [diff] [review] v1 patch Long term, I'd much rather make it so that errors returned from the chanenl's nsIStreamListener simply ends up calling Cancel, but that turned out to be a more involved change. I decided to stick with something safe. Anyways, byte range requests used to complete partial cache entries is the only time that we would have two requests active at a time (one for the cache and one for the transaction).
Attachment #188717 - Flags: review?(cbiesinger)
Comment on attachment 188717 [details] [diff] [review] v1 patch can CancelTransaction lead to OnStopRequest being called again?
It will only get called once. You can cancel a transaction as many times as you like. Moreover, the code is designed to handle OnStopRequest being called by both mCachePump and mTransactionPump.
Comment on attachment 188717 [details] [diff] [review] v1 patch ok, cool
Attachment #188717 - Flags: review?(cbiesinger) → review+
13 years ago
Attachment #188717 - Flags: superreview?(bzbarsky) → superreview+
Attachment #188717 - Flags: approval1.8b4? → approval1.8b4+
Status: ASSIGNED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.