xkmato / mimeparse

Automatically exported from code.google.com/p/mimeparse
MIT License
0 stars 0 forks source link

Wrong ordering of candidates #10

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?

    mimeparse.best_match(["image/jpeg", "text/plain"], "text/*;q=0.3, text/html;q=0.7, text/html;level=1, text/html;level=2;q=0.4, */*;q=0.5")

What is the expected output? What do you see instead?

Expected: 'image/jpeg'
Instead: 'text/plain'

What version of the product are you using? On what operating system?

Version: 0.1.3
OS: Mac OS X 10.6.4, Python 2.6.1
(Using Python version of mimeparse library)

Please provide any additional information below.

The best_match function is using fitness_and_quality_parsed() to order the 
candidate media ranges, but the first value from that is the fitness, which 
corresponds to what rfc2616 calls the "precedence", or the specificity of the 
range to the particular candidate type. The specificity matters, but the major 
ordering factor should be the quality (the client's measure of which media 
ranges are most preferred).

In the example above, image/jpeg should have a quality of 0.5 (from the */*) 
and text/plain should have a quality of 0.3 (from the text/*). The type with 
the higher quality factor is image/jpeg, and it should win.

I'm attaching a patch that fixes this by swapping the elements returned by 
fitness_and_quality_parsed(), along with an extra test for your suite. Hope 
this helps.

Original issue reported on code.google.com by pcannon@gmail.com on 15 Sep 2010 at 11:28

Attachments: