759043 - Cached redirects are processed differently than redirects from the network

Status: NEW

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

Description

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

For example, a redirect from the network that is missing a Location header will end up being treated like an error as far as AppCache fallback is concerned, and otherwise like a 200 response (in particular, we return the redirect's entity). 

But, we will never return the entity of a such a redirect from the cache because we skip over reading the entity for any cached 3xx response. (I am not sure the AppCache fallback is the same as the from-the-network case either.)

Basically, there seem to be many non-obvious differences due to this logic in ProcessResponse:

        PushRedirectAsyncFunc(&nsHttpChannel::ContinueProcessResponse);
        rv = AsyncProcessRedirection(httpStatus);
        if (NS_FAILED(rv)) {
            PopRedirectAsyncFunc(&nsHttpChannel::ContinueProcessResponse);
            LOG(("AsyncProcessRedirection failed [rv=%x]\n", rv));
            rv = ContinueProcessResponse(rv);
        }

vs the from-the-cache case in HandleAsyncRedirect:

        PushRedirectAsyncFunc(&nsHttpChannel::ContinueHandleAsyncRedirect);
        rv = AsyncProcessRedirection(mResponseHead->Status());
        if (NS_FAILED(rv)) {
            PopRedirectAsyncFunc(&nsHttpChannel::ContinueHandleAsyncRedirect);
            ContinueHandleAsyncRedirect(rv);
        }

The logic in ContinueProcessResponse is not the same (or even very similar) to ContinueHandleAsyncRedirect.

See also bug 747215 and bug 738484, which are related.

Comment 1

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 2

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258