88
edits
Plugins:GenericHttpMethod: Difference between revisions
Jump to navigation
Jump to search
talk about redirects
(talk about redirects) |
|||
| Line 25: | Line 25: | ||
= Current Proposal = | = Current Proposal = | ||
* Last modified: August | * Last modified: August 31, 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 67: | Line 67: | ||
</pre> | </pre> | ||
=== Open Issues | == Redirect Handling == | ||
We currently consider two use cases with respect to handling HTTP redirects: | |||
# "best effort" - follow redirects automatically, when allowed | |||
# "full control for plugin" - expose all information to the caller, and let it decide | |||
In the second mode, the method would treat an [http://tools.ietf.org/html/rfc2616#section-10.3 HTTP redirect] just like any other HTTP status. This means that the caller needs to detect the status (3xx), and obtain the [http://tools.ietf.org/html/rfc2616#section-14.30 Location response header] to follow the redirect. | |||
== Open Issues == | |||
* 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?) | ||