-
Notifications
You must be signed in to change notification settings - Fork 5
HTTPStates
So someone came to us recently and pointed to Webmachine. Webmachine is conceptually very similar to Magpie, but Magpie is as far as we can tell more generic in it's implementation and it's approach. However webmachine has a nice little graphic of the Finite State Machine that they implement. Here's the breakdown on how these line up to Magpie.
This probably should be handled (for maintenance downtimes) via the plack
layer with HTTP::Throwable. If you need to deal with it programmatically
you can use Magpie::Transformer::ServiceUnavailable.
As for hooks into the pipeline, this could be done at many stages and is application specific. We leave it up to you where you add in this feature.
The HTTP 1.1 spec says that this is defined for "all known resources" on the server. However Magpie neither operates on the Server level, nor knows (or cares to know) at a global level what every resource implements.
Currently Magpie is returning 501 Not Implemented errors for unimplemented resources on a per-resource level. We're trying to figure out how to properly handle those cases and will adjust accordingly.
Mapgie has no intrinsic limits on Request URIs that Plack doesn't have. This definitely should be handled at the Plack/PSGI Server level.
Magpie Resources (via the resource Base class) will deny any non HTTP 1.1 method as "Not Allowed". (currently this is in a branch)
This should again be handled at the Plack/PSGI server level. Magpie relies on the Plack environment being properly setup. However if we get something that Plack::Request->new() can't parse we will throw a 400.
Authorization can definitely be handled at the Plack level, or by Plack middleware. There is middleware for Basic and Digest Auth as well as more advanced authentication frameworks on CPAN. These can be natively as pipeline components via the configuration.
This should be handled by the Auth component.
Support for this is being looked at. It would be handled at theContent-Negotiation stage in Magpie::Match.
Support for this is being looked at. It would be handled at the Content-Negotiation stage in Magpie::Match.
Like URI length, Magpie has no inherent size restrictions here.
Magpie handles all HTTP methods identically (that it is processes them through to the Resource stage of the pipeline). This is handled by the Resource stage explicitly where the default is a 200 OK.
This means any pipeline stages *before the Resource that explicitly register interest in a OPTIONS method will have a chance to weigh in.
Support for this is being looked at. It would be handled at the Content-Negotiation stage in Magpie::Match.
Support for this is being looked at. It would be handled at the Resource level in Magpie.
This can be easily handled by Plack::Middleware::ConditionalGET and Plack::Middleware::ETag. These components may be added automatically in the future.
This is handled by the Resource class either via the PUT method, or via a possible resource role that wraps the other HTTP methods method.
Is handled explicitly by the Resource class.