Dereferencing widgets://

So, somewhat ignoring the fact that we were going to plot and scheme about what Installable Web Apps could be… and Web APIs… I’ve had a first crack at making widget:// behave more like a HTTP request. This should solve a bunch of problems, including allowing widgets to work with inner package XHR (YaY! jquery mobile FTW!).

From the updated Widget URI Spec (I rewrote most of it!):

This section describes how a user agent is supposed to respond requests to retrive resources from a widget URI. The purpose is to make responses “look and feel” as much as possible like regular HTTP requests.

To dereference a widget URI to a file in a widget package a user agent MUST apply the rules for dereferencing a widget URI.

The rules for dereferencing a widget URI are as follows:

1. If the request is not a GET request, return a 501 Not Implemented response and terminate this algorithm.
2. If the URI uses the scheme ‘widget’, but is not a valid widget URI, return a 400 Bad Request response and terminate this algorithm.
3. If the URI uses the scheme ‘widget’, but the authority does not match the one assigned to this package, return a 403 Not Allowed response and terminate this algorithm (i.e., prevent inter-widget content access).
4. If the user agent implements [[!Widgets]] (for the purpose of internationalization):
   1. Let potential-file be the result of running the rule for finding a file within a widget package using the path component as its parameter.
5. Otherwise,
   1. Let path be the path to the file being sought by the user agent.
   2. Let potential-file be the result of attempting locate the file at path
6. If potential-file is not found, return a 404 Not Found response.
7. If retrieving potential-file results in a error (e.g., the file is corrupt), return a 500 Internal Server Error with an optional message describing the error in the response body.
8. Let content-type be the result of applying the rule for identifying teh media type of a file using potential-file as an argument.
9. Ruturn a 200 OK response, with the value of content-type as the Content-Type header, and with potential-file as the response body.

Boom! done 🙂 Ok, not done… but it’s a good strawman. Let me know what you think.