*** Bug 31957 has been marked as a duplicate of this bug. ***

Done. nsSocketTransport will also fire OnStart/OnStop in pairs.

not fixed yet

BTW if I enable it to fire OnStart in failure cases (such as bad host/etc) - it will still loop and will crash running out of stack in URILoader. So, smth. isn't entirely fixed there.

that's probably because my bug was to only handle the cancel case. That is, my code is only invoked if we explicitly receive a cancel code..i didn't know we had a problem or issue with passing other codes.

M16 has been out for a while now, these bugs target milestones need to be updated.

mscott/valeski Would you guys help me assess this bug's importance for nsbeta3? It appears that this is not completely fixed yet. Can we live without the full and proper fix? Thx.

no response... minus.

Not needed for now - resetting to future

pulling in ruslan's necko bugs ->darin

http bugs to "Networking::HTTP"

See my comments on bug 25045. I'd like to see a OnFailRequest method added to nsIStreamObserver. This would allow us to bypass OnStartRequest in cases where the channel has found an error and has not yet called OnStartRequest.

the sole reason for this bug was to enforce OnStart calls in *all* cases. The semantics are that nsIStreamObserver callback generators are required to send onStart|onStop combos *always.* If we change this, we'll have to change all the nsIStreamObserver callback generators to *not* fire OnStop's which wouldn't be trivial; much more work, IMO, than fixing consumers who aren't handling the semantics properly.

removing stale nsbeta3 keyword.

ok, i believe that we do send OnStart's in all cases, so marking FIXED.

VERIFIED, I suppose, since I think we do too :)