On Thu, 12 Feb 2015, Ian Cordasco wrote:

So that particular problem you mention is an issue with the Routes
package. It assumes you will define very (method, route) that you wish to
handle and it’ll 404 everything else (because no definition was found). If
we used better (slightly higher level) frameworks, we probably wouldn’t
have to concern ourselves with defining those combinations for things that
/should/ intuitively return a 405. Miguel has run into this before and
only recently was able to fix it in one of the projects.

For sake of completeness:

* I found it in general in WSME, and made a pending fix[1]
* It's easy to make happen in Pecan if you're not careful.

In my experience it is actually easier to ensure good 404 and 405
behavior using a dispatcher that is very explicit about matching
(method, route) tuples with handler wsgi callables and then has a
static map of where it should 404, where it should 405 and when it
405s what Allow should say. For that I like selector[2]. Things that
"want to do it for you" are opaque and have to guess, guessing leads
to errors.

But that's not really on topic. Maybe another time?

[long list of relevant RFCs snipped for brevity]

Yes there are a lot of them, and I agree we shouldn't make everyone
read all of them, we'd never get back to the task at hand.

I _think_ what you're saying is that you're +5 on the need to
paraphrase but wish we had better tools. That suggests at least in
the short term we need to be doing some paraphrasing. The facility
with you rattled off that long list makes you a good volunteer.

There’s a lot to read, but it really is necessary to know the standards so
more discussions like the one that took place on
https://review.openstack.org/#/c/141229/ don’t happen. It seems to me many
of our APIs have been built without proper research into standards for how
they should be built.

Yeah. Agree. That's the world we live in, isn't it?

[1] https://review.openstack.org/#/c/154066/
[2] https://pypi.python.org/pypi/selector (not very active, but
    still works)

Chris Dent tw:@anticdent freenode:cdent
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Reply via email to