Changeset 103629 in webkit

Timestamp:

Dec 23, 2011, 8:36:18 AM (14 years ago)

Author:

[email protected]

Message:

Synchronous XHR in window context should not support new XHR responseTypes for HTTP(S) requests
​https://bugs.webkit.org/show_bug.cgi?id=72154

Source/WebCore:

Per the latest W3C editor draft: ​http://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html
This is a spec-mandated attempt to thwart and otherwise discourage the use of synchronous XHR
in the window context by deliberately not exposing newer functionality. Here we are disabling
the use of responseType in synchronous HTTP(S) XHR requests from the window context.

When a user attempts this action, an InvalidAccessError exception is thrown and a message is
printed to the console to further explain.

Renamed reportUnsafeUsage to a more generic name, and hoisted it up so it would be defined
earlier and thus referenceable by setResponseType.

Reviewed by Alexey Proskuryakov.

Test: fast/xmlhttprequest/xmlhttprequest-responsetype-sync-request.html

• xml/XMLHttpRequest.cpp:

(WebCore::logConsoleError):
reportUnsafeUsage -> logConsoleError
(WebCore::XMLHttpRequest::setResponseType):
(WebCore::XMLHttpRequest::setRequestHeader):
reportUnsafeUsage -> logConsoleError
(WebCore::XMLHttpRequest::getResponseHeader):
reportUnsafeUsage -> logConsoleError
(WebCore::XMLHttpRequest::didFail):
reportUnsafeUsage -> logConsoleError

LayoutTests:

New tests that validate synchronous HTTP(S) XHR requests from the window context
cannot use responseType, while other protocols continue to work.

Reviewed by Alexey Proskuryakov.

• fast/xmlhttprequest/xmlhttprequest-responsetype-sync-request-expected.txt: Added.
• fast/xmlhttprequest/xmlhttprequest-responsetype-sync-request.html: Added.

Location:

trunk

Files:

• LayoutTests/ChangeLog (modified) (1 diff)
• LayoutTests/fast/xmlhttprequest/xmlhttprequest-responsetype-sync-request-expected.txt (added)
• LayoutTests/fast/xmlhttprequest/xmlhttprequest-responsetype-sync-request.html (added)
• Source/WebCore/ChangeLog (modified) (1 diff)
• Source/WebCore/xml/XMLHttpRequest.cpp (modified) (6 diffs)

trunk/LayoutTests/ChangeLog

@@ +1 @@
+2011-12-23  Jarred Nicholls  <[email protected]>
+
+        Synchronous XHR in window context should not support new XHR responseTypes for HTTP(S) requests
+        https://bugs.webkit.org/show_bug.cgi?id=72154
+
+        New tests that validate synchronous HTTP(S) XHR requests from the window context
+        cannot use responseType, while other protocols continue to work.
+
+        Reviewed by Alexey Proskuryakov.
+
+        * fast/xmlhttprequest/xmlhttprequest-responsetype-sync-request-expected.txt: Added.
+        * fast/xmlhttprequest/xmlhttprequest-responsetype-sync-request.html: Added.
+
 2011-12-23  Ilya Tikhonovsky  <[email protected]>
 

trunk/Source/WebCore/ChangeLog

@@ +1 @@
+2011-12-23  Jarred Nicholls  <[email protected]>
+
+        Synchronous XHR in window context should not support new XHR responseTypes for HTTP(S) requests
+        https://bugs.webkit.org/show_bug.cgi?id=72154
+
+        Per the latest W3C editor draft: http://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html
+        This is a spec-mandated attempt to thwart and otherwise discourage the use of synchronous XHR
+        in the window context by deliberately not exposing newer functionality. Here we are disabling
+        the use of responseType in synchronous HTTP(S) XHR requests from the window context.
+
+        When a user attempts this action, an InvalidAccessError exception is thrown and a message is
+        printed to the console to further explain.
+
+        Renamed reportUnsafeUsage to a more generic name, and hoisted it up so it would be defined
+        earlier and thus referenceable by setResponseType.
+
+        Reviewed by Alexey Proskuryakov.
+
+        Test: fast/xmlhttprequest/xmlhttprequest-responsetype-sync-request.html
+
+        * xml/XMLHttpRequest.cpp:
+        (WebCore::logConsoleError):
+        reportUnsafeUsage -> logConsoleError
+        (WebCore::XMLHttpRequest::setResponseType):
+        (WebCore::XMLHttpRequest::setRequestHeader):
+        reportUnsafeUsage -> logConsoleError
+        (WebCore::XMLHttpRequest::getResponseHeader):
+        reportUnsafeUsage -> logConsoleError
+        (WebCore::XMLHttpRequest::didFail):
+        reportUnsafeUsage -> logConsoleError
+
 2011-12-23  Alexander Pavlov  <[email protected]>
 

trunk/Source/WebCore/xml/XMLHttpRequest.cpp

@@ -144 +144 @@
 }
 
+static void logConsoleError(ScriptExecutionContext* context, const String& message)
+{
+    if (!context)
+        return;
+    // FIXME: It's not good to report the bad usage without indicating what source line it came from.
+    // We should pass additional parameters so we can tell the console where the mistake occurred.
+    context->addConsoleMessage(JSMessageSource, LogMessageType, ErrorMessageLevel, message);
+}
+
 PassRefPtr<XMLHttpRequest> XMLHttpRequest::create(ScriptExecutionContext* context, PassRefPtr<SecurityOrigin> securityOrigin)
 {
@@ -289 +298 @@
     }
 
+    // Newer functionality is not available to synchronous requests in window contexts, as a spec-mandated 
+    // attempt to discourage synchronous XHR use. responseType is one such piece of functionality.
+    // We'll only disable this functionality for HTTP(S) requests since sync requests for local protocols
+    // such as file: and data: still make sense to allow.
+    if (!m_async && scriptExecutionContext()->isDocument() && m_url.protocolIsInHTTPFamily()) {
+        logConsoleError(scriptExecutionContext(), "XMLHttpRequest.responseType cannot be changed for synchronous HTTP(S) requests made from the window context.");
+        ec = INVALID_ACCESS_ERR;
+        return;
+    }
+
     if (responseType == "")
         m_responseTypeCode = ResponseTypeDefault;
@@ -818 +837 @@
 }
 
-static void reportUnsafeUsage(ScriptExecutionContext* context, const String& message)
-{
-    if (!context)
-        return;
-    // FIXME: It's not good to report the bad usage without indicating what source line it came from.
-    // We should pass additional parameters so we can tell the console where the mistake occurred.
-    context->addConsoleMessage(JSMessageSource, LogMessageType, ErrorMessageLevel, message);
-}
-
 void XMLHttpRequest::setRequestHeader(const AtomicString& name, const String& value, ExceptionCode& ec)
 {
@@ -846 +856 @@
     // A privileged script (e.g. a Dashboard widget) can set any headers.
     if (!securityOrigin()->canLoadLocalResources() && !isAllowedHTTPHeader(name)) {
-        reportUnsafeUsage(scriptExecutionContext(), "Refused to set unsafe header \"" + name + "\"");
+        logConsoleError(scriptExecutionContext(), "Refused to set unsafe header \"" + name + "\"");
         return;
     }
@@ -908 +918 @@
     // See comment in getAllResponseHeaders above.
     if (isSetCookieHeader(name) && !securityOrigin()->canLoadLocalResources()) {
-        reportUnsafeUsage(scriptExecutionContext(), "Refused to get unsafe header \"" + name + "\"");
+        logConsoleError(scriptExecutionContext(), "Refused to get unsafe header \"" + name + "\"");
         return String();
     }
 
     if (!m_sameOriginRequest && !isOnAccessControlResponseHeaderWhitelist(name)) {
-        reportUnsafeUsage(scriptExecutionContext(), "Refused to get unsafe header \"" + name + "\"");
+        logConsoleError(scriptExecutionContext(), "Refused to get unsafe header \"" + name + "\"");
         return String();
     }
@@ -983 +993 @@
     // Network failures are already reported to Web Inspector by ResourceLoader.
     if (error.domain() == errorDomainWebKitInternal)
-        reportUnsafeUsage(scriptExecutionContext(), "XMLHttpRequest cannot load " + error.failingURL() + ". " + error.localizedDescription());
+        logConsoleError(scriptExecutionContext(), "XMLHttpRequest cannot load " + error.failingURL() + ". " + error.localizedDescription());
 
     m_exceptionCode = XMLHttpRequestException::NETWORK_ERR;