88
edits
| Line 21: | Line 21: | ||
= Current Proposal = | = Current Proposal = | ||
* Last modified: August | * Last modified: August 22, 2009 | ||
* Author: Darin Fisher (Google) and Julian Reschke (greenbytes) | * Author: Darin Fisher (Google) and Julian Reschke (greenbytes) | ||
* Contributors: Ian Melven (Adobe) | * Contributors: Ian Melven (Adobe) | ||
| Line 52: | Line 52: | ||
Another callback would then be needed to signal the final result. | Another callback would then be needed to signal the final result. | ||
New NPError codes: | |||
<pre> | |||
// HTTP stack does not support method | |||
#define NPERR_METHOD_NOT_SUPPORTED (NPERR_BASE + nn) | |||
</pre> | |||
=== Open Issues === | === Open Issues === | ||
| Line 57: | Line 63: | ||
* Extend the NPN_RequestURLNotify with a flags parameter controlling how redirects are handled (and leaving room for future extensions?) | * 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?) | * 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?) | ||
edits