1553083 - Decide what cancelling a channel after onStopRequest should do

Status: RESOLVED WONTFIX

(Core :: Networking: HTTP, task, P3)

Comment 1

[Valentin Gosu [:valentin] (he/him)]

If a channel has already completed (called onStopRequest with status = NS_OK), we can still cancel it afterwards.
Currently the method returns success and sets the channel's mStatus to the value Cancel(status) passes to it.
So checking the status afterwards will give you an error code, even though the channel successfully completed, which doesn't seem right.

The alternative would be to either throw if the channel has already completed, or to silently fail (just return NS_OK and don't change mStatus) if onStopRequest has already failed.

I am not sure if there are any consumers of nsIHttpChannel that depend on the current behaviour, but we should consider fixing it.
Do you think this would break anything? Opinions?

Comment 2

[Honza Bambas (:mayhemer)]

IMHO, leave it as is. We have a way to detect if a channel is still 'pending' - which is set in successful asyncOpen and dropped just before onStopRequest + we expose the status code (failure == cancellation). I don't think detection of a cancellation failure is such a common and necessary use case; and as written above - we already have APIs for it, if desired and only possible failure is a cancel after onStopRequest. Carrying the cancellation code may be necessary for some code to propagate errors in some weird way. Also note that double cancellation is a no-op (silent fail) already.

Comment 3

[Dragana Damjanovic [:dragana]]

I would leave it as it is. This is a corner case. I think users of nsHttpChannel when they cancel a channel they really do not care if OnStopRequest is called or not.