Darin Fisher wrote:
> Chris Waterson wrote:
>
> > I'm looking into a bug (5569) that appears to be caused by the
> > assumption that a load observer that receives an OnStartRequest() will
> > always receive a matching OnStopRequest(). Is this assumption valid?
>
> Yes... actually, it is a requirement that an OnStartRequest be paired
> with a corresponding OnStopRequest. For example, if
> nsIChannel::AsyncOpen succeeds, then there _will be_ an OnStartRequest
> followed by zero or more OnDataAvailable's with a fiinal OnStopRequest.
> By the way, it is completely possible that OnStopRequest will be
> followed by another sequence of
> OnStartRequest/OnDataAvailable/OnStopRequest. This happens in the case
> of HTTP authentication, HTTP redirection, and multipart-mixed-replace
> (to name some of the more common examples).
>
> Darin
Currently, the URILoader is broken in such a way that if your protocol does
not have any data (it encounters or something), pairing these to
notification will destroy the original content area leaving the content
empty. This is not desirable. The URILoader has some special hackery which
allows HTTP 202 response and a small subset of request error to behave
properly (eg. doesn't kill the content area when there is no data).
Here is a bug with a patch which address this specific problem (darin please
review patch :-) ):
http://bugzilla.mozilla.org/show_bug.cgi?id=72679
If you look around, you may find more deviations/bugs.
