pyramid

pyramid copied to clipboard

Basically, when a route is matched by URL pattern but fails other predicates like request_method or accept, it should respond with 405 and 406 (for those two), not with 404.

More information: https://groups.google.com/forum/#!topic/pylons-discuss/kyou9QCzbQk

Unfortunately this is difficult to accomplish in Pyramid due to the way the matching machinery works. It doesn't know that it failed due to a request_method predicate or accept predicate.

The programmer is in the best position to look at why the matching failed (predicate_mismatch is raised) and then return the appropriate error to the client.

As @bertjwregeer says, Pyramid's predicate machinery does not really allow for this currently. Predicates that fail to match due to no view being registered for a particular request method or accept= are not "special" in Pyramid's eyes, because Pyramid allows for the registration of custom predicates that are defined completely by a third party user, and are treated exactly like built-in predicates. I am tempted to close this issue because as far as I can tell, there really isn't any sensible resolution to it if the custom predicate feature is to be maintained (which it will be), but I'll leave it open for now in case anyone has some sort of idea.

Maybe we could support this by allowing predicates to raise or return an http exception. That could be caught by the predicate wrapper and passed as an attribute of the PredicateMismatch exception, and then if present _call_view would re-raise the http exception instead of the last PredicateMismatch.

We could add some underlying machinery for handling specific types of errors like 405, 406, 415 such that if a predicate fails there is an associated reason. After predicate processing the reason could be analyzed and converted into a proper response.

I think it would be really nice if Pyramid had better support for automating these specific errors. It's a very large reason why cornice was built in the first place.

We could add some underlying machinery for handling specific types of errors like 405, 406, 415 such that if a predicate fails there is an associated reason. After predicate processing the reason could be analyzed and converted into a proper response.

That sounds interesting. I guess the mecanism would be a custom exception to be raised from predicates, with instance attributes for code/reason, and default exception views configured to catch the exception and return HTTP error response?

I think the biggest immediate improvement would be for the PredicateMismatch exception to have more useful metadata attached to it about why it was raised. It'd be handy to know which predicates were tested and which one failed, for each view that was tested. From there, it may be possible to derive some useful information that can be used. It's always going to be application-specific though because Pyramid's view lookup is not geared toward detecting those types of errors - it's too general for that. You can easily define certain combinations of predicates that look like a certain error but are not because the predicates overlap in weird ways. However, if every view failed because of the request_method predicate, then you can easily raise a 405 and that'd already be an improvement.