Incorrect order of best matching types? about python-mimeparse HOT 5 CLOSED

Hi @marcinn , sorry for the delay. Yup, that quote is spot on and I think this package should respect that rule.

I think the change I proposed in #26 is the right step forward. It doesn't break any of the previously existing unit tests and - prior to the change - the behavior for using qvalue server-side was simply undefined. Now, we're defining it according to the RFC.

from python-mimeparse.

Thanks @wojcikstefan! Sorry for late response. I missed your reply. Best regards!

from python-mimeparse.

Hi @marcinn ! Typically the quality is specified on the types the client accepts and not the server's acceptable types. I haven't seen something like this before. Can you point me to some resource (e.g. a section in the RFC) where this behavior is described?

I preemptively implemented #26 in case we agree to do it in the way you described.

from python-mimeparse.

I've just saw that RFC7231 section 5.3.1 contains a phrase which describes what I'm doing:

This weight is referred to as a "quality value" (or "qvalue") because the same parameter name is often used within server configurations to assign a weight to the relative quality of the various representations that can be selected for a resource.

I'm creating a server which should serve a best matching and preferred representation. When client accepts anything (*/*), the server should respond with most-common/preferred mediatype. My implementation is based on mimeparse.best_match(). I'm passing acceptable media types and the client's header as arguments, but the function fails in that case.

I've declared a qvalue for a server's accetable types in a similar way how @Produces annotation work (please look at this), but using q instead of qs believing that mimeparse will do such matching automatically. But it didn't.

I realize that mimeparse.best_match() is written mostly for client's content matching and I can rewrite media type negotiation without using mimeparse, of course, but I'm also wondering about implementing it inside exisitng package - it is designed to do such things, I think. That's why I'm asking.

Looking at your patch I can just say that "the fix" is quite simple, but it is related to quality_and_fitness_parsed(). So it affects not only best_match(), but also quality_parsed().

Your patch works for me, but it may break compatibility for others (in cases where clients are not sending Accept header or asking server for anything). Is this a good idea? I don't know...

from python-mimeparse.

v1.6.0 released

from python-mimeparse.