61007 2011-05-17 17:46:59 -0700 Allow custom schemes to use XMLHttpRequest 2025-01-09 10:11:44 -0800 1 1 1 Unclassified WebKit XML 528+ (Nightly build) All All UNCONFIRMED https://bugs.webkit.org/show_bug.cgi?id=117313 P3 Normal --- 0 joe webkit-unassigned abarth ap magreenblatt syoichi oldest_to_newest 405426 0 93852 joe 2011-05-17 17:46:59 -0700 Created attachment 93852 Patch to DocumentThreadableLoader to allow custom schemes to use XMLHttpRequest FWIW, I'm using Chromium Embedded Framework, with WebKit v534.28. Currently, URLs with custom schemes don't work with XMLHttpRequest, even with CORS supported by the scheme handler. DocumentThreadableLoader::makeSimpleCrossOriginAccessRequest in documentthreadableloader.cpp fails because "Cross origin requests are only defined for http" (comment in the code) This is enforced by testing protocolInHTTPFamily(). makeSimpleCrossOriginAccessRequest is called because in the DocumentThreadableLoader constructor, cross origin requests are handled as simple, unless 1. forcePreFlight is set as an option 2. isSimpleCrossOrigianAccessRequest fails Unfortunately, because isSimpleCrossOriginAccessRequest only uses the method and the header fields as input, it can't tell if the URL has a custom scheme. The result is that custom schemes get treated along with "SimpleCrossOriginAccessRequests", and subsequently fail the protocolInHTTPFamily() test in makeSimpleCrossOriginAccessRequest. I'd like to suggest that custom schemes are /not/ "simple". In fact, if CORS is to be used with custom schemes, custom schemes must not be treated as simple in order for the preflight be triggered (although I guess I'm not sure if preflight is actually required). Considerations: 1. The easiest solution is to just add a test for protocolInHTTPFamily before calling makeSimpleCrossOriginAccessRequest. 2. Alternatively, one could change the signature of isSimpleCrossOriginAccessRequest to pass the request and let the method check if it is a custom scheme as part of its determination. This is probably a cleaner solution from a code maintenance standpoint, but requires changing more code now. 3. Because of potential security risks from scheme handlers that had counted on webkit to prevent any access via AJAX, perhaps we need a more robust solution. One suggestion: a registration method so that schemes can pro-actively elect to have CORS mediate requests. I've attached a patch for option #1. 405428 1 93852 abarth 2011-05-17 17:59:42 -0700 Comment on attachment 93852 Patch to DocumentThreadableLoader to allow custom schemes to use XMLHttpRequest This needs a ChangeLog and a test, at least. 409278 2 magreenblatt 2011-05-24 15:52:52 -0700 As an alternative approach we could do the following: 1. Add support in googleurl/src/url_util.h for registering schemes that should be treated as HTTP protocol handlers (AddHttpProtocolScheme, IsHttpProtocol). This would be similar to the existing support for registering standard protocols. 2. Change KURLGooglePrivate::initProtocolIsInHTTPFamily() to call the new url_util::IsHttpProtocol() method instead of only checking for hard-coded "HTTP" and "HTTPS" values. This approach has the following advantages: A. The change only affects Chromium-based clients. B. The user must explicitly indicate that a custom scheme should be treated as an HTTP protocol handler by calling url_util::AddHttpProtocolScheme(). This addresses the concern that existing scheme handlers will see behavior changes. C. All behavior that is currently HTTP-specific (call sites using protocolInHTTPFamily) will now recognize the new scheme with no additional changes required. What do you think? 409693 3 magreenblatt 2011-05-25 09:40:28 -0700 An implementation for comment#2 is available here: http://code.google.com/p/chromiumembedded/issues/detail?id=246 I'm not exactly sure how to pursue getting this committed since it spans both googleurl and webkit projects. Suggestions are welcome. 411502 4 magreenblatt 2011-05-27 09:40:19 -0700 It was explained to me off-list that this bug is to allow custom /non-standard/ schemes to execute cross-origin XHR. Please ignore my comments #2-3 above, I was able to implement what I needed for custom /standard/ schemes by using the origin whitelist capabilities in WebSecurityPolicy. 411536 5 joe 2011-05-27 10:47:06 -0700 Actually, Marshall, I think your fix may also allow non-standard schemes, as WebSecurityPolicy should support sources without hosts. I'll try out the Cef revision and let you know if it works for my case. 93852 2011-05-17 17:46:59 -0700 2011-05-17 17:59:42 -0700 Patch to DocumentThreadableLoader to allow custom schemes to use XMLHttpRequest DocumentThreadableLoader.customSchemeAJAX.patch text/plain 813 joe SW5kZXg6IERvY3VtZW50VGhyZWFkYWJsZUxvYWRlci5jcHANCj09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCi0tLSBEb2N1 bWVudFRocmVhZGFibGVMb2FkZXIuY3BwCShyZXZpc2lvbiA4MjgyNykNCisrKyBEb2N1bWVudFRo cmVhZGFibGVMb2FkZXIuY3BwCSh3b3JraW5nIGNvcHkpDQpAQCAtOTIsNyArOTIsOCBAQA0KICAg ICBjcm9zc09yaWdpblJlcXVlc3QtPnJlbW92ZUNyZWRlbnRpYWxzKCk7CiAgICAgY3Jvc3NPcmln aW5SZXF1ZXN0LT5zZXRBbGxvd0Nvb2tpZXMobV9vcHRpb25zLmFsbG93Q3JlZGVudGlhbHMpOwog Ci0gICAgaWYgKCFtX29wdGlvbnMuZm9yY2VQcmVmbGlnaHQgJiYgaXNTaW1wbGVDcm9zc09yaWdp bkFjY2Vzc1JlcXVlc3QoY3Jvc3NPcmlnaW5SZXF1ZXN0LT5odHRwTWV0aG9kKCksIGNyb3NzT3Jp Z2luUmVxdWVzdC0+aHR0cEhlYWRlckZpZWxkcygpKSkKKyAgICBpZiAoIW1fb3B0aW9ucy5mb3Jj ZVByZWZsaWdodCAmJiBpc1NpbXBsZUNyb3NzT3JpZ2luQWNjZXNzUmVxdWVzdChjcm9zc09yaWdp blJlcXVlc3QtPmh0dHBNZXRob2QoKSwgY3Jvc3NPcmlnaW5SZXF1ZXN0LT5odHRwSGVhZGVyRmll bGRzKCkpCisJCSYmIHJlcXVlc3QudXJsKCkucHJvdG9jb2xJbkhUVFBGYW1pbHkoKSkKICAgICAg ICAgbWFrZVNpbXBsZUNyb3NzT3JpZ2luQWNjZXNzUmVxdWVzdCgqY3Jvc3NPcmlnaW5SZXF1ZXN0 KTsKICAgICBlbHNlIHsKICAgICAgICAgbV9hY3R1YWxSZXF1ZXN0ID0gY3Jvc3NPcmlnaW5SZXF1 ZXN0LnJlbGVhc2UoKTsK