Background

A feature targeted for Firefox 3 is to allow web services to act as "content handlers" in basically the same way that desktop applications do today. During the development of this feature, however, there's been a growing debate about whether the current GET-only specification from the WHAT WG will work well for all the basic use cases.

See: http://www.whatwg.org/specs/web-apps/current-work/#custom-handlers

Specifically, the biggest issue is that the current spec only allows information to be passed to the web services via a URI. This can pose challenges in at least a few scenarios:

• The data cannot be referenced by a URI (e.g., microformats)
• The URI is not publicly accessible (e.g., behind a firewall or login)

Use Cases

I believe the following set of use cases are both common (what we're trying to enable) and relatively complete (expose all the issues/considerations):

1. Click a mailto: link
   • Data needed by web app = URI parameters for To:, Subject:, etc.
   • Works? GET = yes ; POST = no (at least not easily)
2. Subscribe to a feed
   • Data needed by web app = feed URL
   • Works? GET = yes ; POST = no (unless feed has rel="self" URI... still inefficient)
3. Open a word attachment from Yahoo! Mail in Google Docs & Spreadsheets
   • Data needed by web app = .doc file
   • Works? GET = no ; POST = yes (though perhaps slow)
4. Add an event on a web page to Google Calendar
   • Data needed by web app = hCal microformat
   • Works? GET = no ; POST = yes

Considerations

In the discussion so far, the debate about introducing POST has centered around the user experinece and security/privacy.

User Experience

• Success -- What is the likelikhood that it will actually work?
• Performance -- How well does it perform?

Going out on a limb here... but I'll say that something having a reasonable chance of working trumps how fast it will work. In the case of files and microformats, a GET-based approach will often not work (in the case of files) or never work (in the case of microformats). POST-based approach does introduce the problem that uploading the file to a web app could take considerable time.

  Would likely need control UI for uploading to web service  ("Upload Manager" :-)

Security Privacy

Since the mechanisms are largely the same, it seems the biggest potential differences between GET vs. POST as far as security and privacy are concerned is precisely what data can be "leaked" to a third party. Each has its own risks:

• GET
  • Origin -- The URI exposes where the data come from
  • File Name -- The path or filename in the URI may give some indication of its contents (e.g, "http://witehouse.gov/Bin_Laden_Determined_to_Attack_Inside_US.doc")
  • Credentials -- URI may contain a username and/or password
• POST
  • File Contents -- It is obviously the user's intent to expose the file contents... however they may have set a default web app for a file type for personal data and then later click to open a sensitive document, forgetting that it will get sent to that web app.

 Both GET & POST need some strategy for communicating potential data leakage to user

Implementation Approaches

Am I missing any?

1. GET-only -- The current WHAT WG approach.
2. POST-only -- Wouldn't make any sense for protocol handlers.
3. User Chooses -- User would choose how the data would be passed. Obviously, very few users are technically sophisticated enough to make this decision.
4. Web App Chooses -- Each web app would choose whether it wanted data sent via GET or POST at registration time and per protocol, MIME-type, etc.
5. Per Use Case -- Update the standard to segment by use case which use GET and which use POST. For example, it could be something like:
   • Protocols use GET
   • Feeds use GET -- A special case of Files where the user intent is not for the app to process the data in the file, but to store it's URI for future updates. It's also a special case in that it can be triggered both by either a protocol (feed:/) or a MIME-type (application/rss+xml).
   • Files use POST
   • Microformats use POST

Proposal

Out of the three remaining approaches, the last seems the most functional and least ambiguous (i.e., what does the browser do if a web app registers both GET and POST).

Perhaps it could look something like this:

  /**
  * @param  protocol  The protocol to register for, e.g., "mailto"
  * @param  uri       Includes a %s for substituting the escaped protocol URI
  * @param  title     User-facing title of the web app
  */
  registerProtocolHandler(protocol, uri, title)

  /**
  * @param  feed-type Type of feed ("text", "audio", "video", "image"?... or format?)
  * @param  uri       Includes a %s for substituting the escaped protocol URI
  * @param  title     User-facing title of the web app
  */
  registerFeedHandler(feed-type, uri, title)

  /**
  * @param  mime-type The MIME-type of the data, e.g, "application/pdf"
  * @param  uri       The URI to POST the data to
  * @param  title     User-facing title of the web app
  */
  registerFileHandler(mime-type, uri, title)

  /**
  * @param  name      The type of microformat
  * @param  uri       The URI to POST the data to
  * @param  title     User-facing title of the web app
  */
  registerMicroformatHandler(name,uri,title)

Relationship to current WHAT WG Spec

• registerProtocolHandler is unchanged
• registerContentHandler would be a deprecated alias to registerFeedHandler (since that's all it's been used for to date)
• registerFileHandler and registerMicroformatHandler are new