298726 - add support for suspending nsHttpChannels *before* they actually try to open a socket

Status: RESOLVED FIXED

(Core :: Networking, enhancement)

Description

[timeless]

scenario:
1. user clicks a link
2. gecko asks necko to load an http url
3. necko sends http-on-modify-request
4. an observer wants to modify the request without needing to reconstruct the
observers attached to it.
5. the observer is perfectly happy with no new outbound connections being made
at this time.
6. time passes
7. the observer decides to modify the request
8. the observer decides it's ok to let the httpchannel open a socket and connect.
9. the observer decides it's ok for other outbound connections to happen.


we have a fun problem. a user clicks a link and necko is told to go get the
page. necko sends http-on-modify-request. we, unfortunately don't want necko to
actually load that page right now. this is amusingly enough the opposite of bug
286807. we want to suspend the request such that no one realizes that the
request is not going to happen right now. precisely the way the request got
stuck in the offline mess. because, as it happens, our evil user wants to see
the exact request, and maybe tweak it. but, we're of course running on the gecko
ui thread, so we can't quite just stop, and if we let go of the ui thread, the
scripts we're running move and the request will probably continue. if it was
actually canceled, other random state changes will happen which we certainly
can't handle. anyway, based on my experience w/ the offline mess it looks like
it should be possible to get the request stuck intentionally.

biesi notes that live requests are periodically checked, so doing something like
what i'm suggesting would need a bit of work. the symptom of bug 286807 was that
no requests to that server could be made (and if you filled all slots, no
requests could be made to any server) because there were no slots available -
which is precisely what i need :).

I temporarily (measured in quarter hours or minutes or something - user epochs)
want no slots. when the user gets around to deciding how the user wants to
tinker with the request, we'll modify the request, and unfreeze (free up) some
slots to let it continue. for a time i want no available slots :)

-- note: offline mode does not satisfy our requirements at all, we can't go
killing live requests and we certainly don't want to go around killing random
open ports [especially one's we opened ourselves], nor do we want to confuse the
poor browser making the request, we especially don't want the browser to
consider visiting the cache for an answer --

at the present time, i believe the granularity level of stopping all outbound
requests would be sufficient, although we might want to be able to only stop
requests to specific hosts (perhaps to allow venkman to report its use count, or
perhaps so that we can read online documentation).

-- note: causing connections to be refused does not satisfy our requirements.
the connections must survive and be connected to their original
requesters/listeners.

-- i've quickly scanned nsHttpChannel::Suspend and i'm 99% certain that it
doesn't do anything useful until it's too late (from my perspective), and given
that biesi didn't immediately counter my request with a suggestion to that
effect, i'm fairly confident in the other 1%.

Comment 1

[Darin Fisher]

-> default owner

Comment 2

[Patrick McManus [:mcmanus]]

tracking protection made this work