So I'm having to implement multiple language support on our server by handling the Accept-Language header, and have some questions that aren't really addressed in the RFC:  http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html

So, a client can not only specify multiple languages, but can assign a quality value to each one to denote an order of preference.  i.e. from the spec,

Accept-Language: da, en-gb;q=0.8, en;q=0.7
would mean: "I prefer Danish, but will accept British English and other types of English."

First, it seems WTFy to me that you're assigning quality values instead of just a comma-separated ordered list.  Makes parsing the thing that much harder because now I have to sort it.  And I really don't care whether you like british english .2 more, or .1 more.  I only care about the order.

But on to my question: How do I handle (or do I need to handle) languages that have the same quality?  i.e. 

Accept-Language: da, en

Both would default to a quality of 1.  Should they go into an arbitrary order, or the order they were recieved in, or can I just consider that an invalid use case and handle it in the most convenient way for me (ignoring the second one)?

A more elaborate example is

       Accept: text/plain; q=0.5, text/html,
               text/x-dvi; q=0.8, text/x-c

Verbally, this would be interpreted as "text/html and text/x-c are the preferred media types, but if they do not exist, then send the text/x-dvi entity, and if that does not exist, send the text/plain entity."

vt_mruhlin:

Both would default to a quality of 1.

Fuck 'em.

Manually add a value of >1 to inqualified entries, in the the order they appear, so that text/html gets 1.2, and text/x-c gets 1.1. Then sort.

The result is utterly predictable to a user, and compliant with the example result => therefore good.

Ah thanks.  I was only looking at the Accept-Language section, and ignoring the Accept section.  Didn't see that example.

 Welcome.