Plugins:GenericHttpMethod

Status

Under Consideration

Problem Summary

1. The plugin API only supports GET and POST. It would be desirable to support other methods defined in RFC 2616, such as DELETE, OPTIONS, and PUT, and also extension methods such as PROPFIND (WebDAV) or PATCH.
2. HTTP request headers can only be set for POST (see NPN_PostURLNotify), but not for GET (NPN_GetURLNotify). This makes it hard to access content-negotiated resources and to control caching (such as by taking advantage of conditional requests).
3. There is insufficient control over handling HTTP redirects. If a redirect is followed automatically, the caller should be able to find out the type of redirect (temporary or permanent) and the new URI. If a redirect was not followed, it should have access to status code and Location header. And finally it should be able to select whether redirects are followed or not. (Note that currently this isn't covered by XmlHttpRequest either, but is a known to-do)
4. Confusion about how invalid URLs (for instance, containing non-ASCII characters or whitespace) need to be handled.

Existing Discussions and Documentation

Related Documentation

• XMLHttpRequest (demonstrates that browsers already support the required functionality and could be used to define certain behaviors, such as how request headers are defaulted and combined)
• Mark Nottingham's XmlHttpRequest Test Cases

Current Proposal

• Last modified: August 21, 2009
• Author: Darin Fisher (Google) and Julian Reschke (greenbytes)
• Contributors: Ian Melven (Adobe)

The current proposal is to add a new method inspired by NPP_URLNotify, adding the missing pieces:

NPError NPN_HttpRequest(
  NPP instance,
  const char* method,
  const char* url,
  const char* target,
  const char* headers,
  PRUInt64 len,
  const char* buf,
  NPBool file,
  void* notifyData);

and have a matching plugin method that would be called as soon as status line and response headers are received (see headers-received state in XmlHttpRequest):

void NPP_HttpResponseNotify(
  NPP instance,
  const char* url,
  int status,
  const char* headers, // potentially including the status line
  void* notifyData);

Another callback would then be needed to signal the final result.

Open Issues

• Extend the NPN_RequestURLNotify with a flags parameter controlling how redirects are handled (and leaving room for future extensions?)
• Do we need a separate callback for the final state (as in NPN_PostURLNotify. or should we just keep calling NPP_HttpResponseNotify and add a status field as in XmlHttpRequest?)