[webkit-dev] Custom scheme handlers & XHR [plain text]

[Joe Andrieu]

[my apologies that last email got completely scrubbed in the archives]

Howdy,

I've been working with the Chromium Embedded Framework, trying to get a 
custom scheme handler to process AJAX queries from a page loaded from a 
file: URL, i.e., from a null origin.  The main motivation is that I want 
to use my custom scheme from a javascript library (jsTree) that has 
built-in support for progressive rendering via AJAX. The secondary 
motivation is that in a mash-up world, XHR would be a lot more useful if 
there were a way to use it for any valid URL.

I've spoken with abarth and ap about this and while I don't want to 
suggest they support my proposal, they've helped me frame the issues. 
Adam had previously suggested I use CORS to handle cross-origin XHR. I 
added response header support to Cef, but found that WebKit was refusing 
to allow any non-http URLs to make cross-origin requests, even with the 
CORS headers.

Walking through the code, I found that this could be supported with a 
very small change. I submitted a patch for it at 
https://bugs.webkit.org/show_bug.cgi?id=61007 I'm still working on the 
change log and tests, which will take some effort because I've been 
building against Chromium, not WebKit, but I'll figure that out if it 
makes sense to do so.

Alexei suggested I address the following questions:

1) why this is needed. it's a rather significant change in an 
under-specified platform area, can you easily avoid changing WebKit to 
serve your need?

2) is the need interesting to anyone else?

3) what does Mozilla do?

Here are some answers, to see if this is a path worth exploring.

1) why this is needed. it's a rather significant change in an 
under-specified platform area, can you easily avoid changing WebKit to 
serve your need?

There are a number of javascript libraries that have AJAX deeply 
embedded. If AJAX supported custom schemes, it would be easier to use 
the scheme directly than to modify every library that might be used to 
instead call an injected JS method, especially when you consider various 
issues already solved by XHR, such as asynchrony and authentication. In 
theory (I have not proven it in code), one could use JSONP to access the 
custom scheme, but the handler would have to support the callback 
parameter. Handling the callback may actually be a bit easier than 
supporting CORS, but my understanding is that CORS is the 
forward-looking solution for cross-origin XHR. In which case, JSONP 
would be more of a hack than a long term option.

My biggest frustration is that although Chromium and Cef would allow 
this sort of experimentation (custom schemes with XHR), because of the 
underlying WebKit security assumptions, they can't.

2) is the need interesting to anyone else?

Maybe. I've had some correspondence with Cameron Kaiser of the Overbite 
project, about using the gopher: scheme with AJAX, but I can only say he 
thought it was intriguing but needed a clearer use case. I also think a 
radar: scheme handler would make a lot of sense in an XHR mash-up.

Unfortunately, this is a bit of a catch-22. Because you can't use AJAX 
with anything but http(s), few developers consider a custom-scheme use 
for XHR. However, I think any number of applications worth building a 
browser add-on could benefit from XHR access to a custom scheme. Mine 
certainly would.

3) what does Mozilla do?

I don't know, yet. I've asked on irc #mozilla and I've read through 
their documentation. However, it isn't clear how cross-scheme XHR 
requests are handled. It doesn't say you can't do it, but it also 
doesn't say that you can. If I can't find someone who knows, I'll try 
building a custom protocol handler and see what happens.


In closing, my question is whether or not supporting custom schemes in 
XHR is a good idea. If so, we can figure out the best way to do that. 
The patch I made is probably the easiest, but Alexei pointed out it 
could cause security problems for current scheme handlers that don't 
know anything about CORS.  Handling that robustly would require 
substantially more code than the proposed patch.

This is already a bit more work than I anticipated, but if I can help 
create a viable, long term solution that would open XHR to custom 
schemes, I would be happy to contribute.

-j

-- 
Joe Andrieu
joe at andrieu.net
+1 (805) 705-8651