88
edits
Plugins:GenericHttpMethod: Difference between revisions
→Problem Summary
Rudisherry (talk | contribs) |
|||
| Line 5: | Line 5: | ||
= Problem Summary = | = Problem Summary = | ||
# The plugin API only supports GET and POST. It would be desirable to support other methods defined in [http://tools.ietf.org/html/rfc2616 RFC 2616], such as [http://tools.ietf.org/html/rfc2616#section-9.7 DELETE], [http://tools.ietf.org/html/rfc2616#section-9.2 OPTIONS], and [http://tools.ietf.org/html/rfc2616#section-9.6 PUT], and also extension methods such as [http://tools.ietf.org/html/rfc4918#section-9.1 PROPFIND] (WebDAV) or [http://tools.ietf.org/html/ | # The plugin API only supports GET and POST. It would be desirable to support other methods defined in [http://tools.ietf.org/html/rfc2616 RFC 2616], such as [http://tools.ietf.org/html/rfc2616#section-9.7 DELETE], [http://tools.ietf.org/html/rfc2616#section-9.2 OPTIONS], and [http://tools.ietf.org/html/rfc2616#section-9.6 PUT], and also extension methods such as [http://tools.ietf.org/html/rfc4918#section-9.1 PROPFIND] (WebDAV) or [http://tools.ietf.org/html/rfc5789 PATCH]. | ||
# HTTP request headers can only be set for POST (see [https://developer.mozilla.org/en/NPN_PostURLNotify NPN_PostURLNotify]), but not for GET ([https://developer.mozilla.org/en/NPN_GetURLNotify NPN_GetURLNotify]). This makes it hard to access content-negotiated resources and to control caching (such as by taking advantage of conditional requests). | # HTTP request headers can only be set for POST (see [https://developer.mozilla.org/en/NPN_PostURLNotify NPN_PostURLNotify]), but not for GET ([https://developer.mozilla.org/en/NPN_GetURLNotify NPN_GetURLNotify]). This makes it hard to access content-negotiated resources and to control caching (such as by taking advantage of conditional requests). | ||
# 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 [http://www.w3.org/TR/XMLHttpRequest/#notcovered to-do]) | # 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 [http://www.w3.org/TR/XMLHttpRequest/#notcovered to-do]) | ||