[Webkit-unassigned] [Bug 36156] XHR 'progress' event code assumes wrongly that expectedLength >= 0

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=36156


Hans Muller <giles_joplin at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |giles_joplin at yahoo.com




--- Comment #3 from Hans Muller <giles_joplin at yahoo.com>  2011-11-22 12:15:52 PST ---
The problem is in void XMLHttpRequest::didReceiveData(const char* data, int len), here:

    if (!m_error) {
        long long expectedLength = m_response.expectedContentLength();
        m_receivedLength += len;

        if (m_async) {
            bool lengthComputable = expectedLength && m_receivedLength <= expectedLength;
            m_progressEventThrottle.dispatchProgressEvent(lengthComputable, m_receivedLength, expectedLength);
        }
        ...
     }

According to the W3C (Candidate Recommendation) ProgressEvents spec, the event's total field should be 0 if the content length can't be computed.  This happens, for example, when HTTP chunked transfer encoding is used, as in Glenn's PHP test case.

On OSX, when the content length can't be computed, m_response.expectedContentLength is -1 (this is the expected behavior from NSURLResponse).  It's being assigned to the dispatchProgressEvent() method's -unsigned- long long "total" parameter which just yields a nonsensically large value.

A defensive fix to the problem is to avoid passing any negative value as the dispatchProgressEvent's total parameter and to always use 0 when lengthComputable is false.

        if (m_async) {
            bool lengthComputable = expectedLength > 0 && m_receivedLength <= expectedLength;
            unsigned long long total = lengthComputable ? expectedLength : 0;
            m_progressEventThrottle.dispatchProgressEvent(lengthComputable, m_receivedLength, total);
        }


This produces the correct results for the Glenn's test case.  I'm working on a patch, a regression test, and checking the fix on Windows.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.