I have a application that offers different kinds of authentication methods (Basic and Negotiate).
The problem is that Firefox uses them in the order they are listed in the HTTP header.
waitress currently sorts the headers by key and value which because Firefox to use Basic instead of Negotiate because it starts with B.
only sort the headers by key not by value
extra : rebase_source : 28c8db5c527838341f125e10f8ec770352c92b75
Should the headers be sorted at all by waitress?
I don't know if there are any cases where the key order matters.
I guess it is easier to read when debugging.
Testing comes to mind, when output matters
I found another place that manipulates the headers.
This time not only the order of the headers but the content.
In line 200 The headers get "capitalized".
But one of my clients seems to ignore Authenticate headers like 'Www-Authenticate' and only reads headers like 'WWW-Authenticate'
OK, I found the according text in the RFC.
http://www.ietf.org/rfc/rfc2616.txt (4.2) says
"...The order in which header fields with the same field-name are received is therefore significant to the interpretation of the combined field value, and thus a proxy MUST NOT change the order of these field values when a message is forwarded..."
It also says
"Field names are case-insensitive"
So why would waitress capitalize the header names?
For what it's worth, I think you've misinterpreted the RFC section you quote. The section you quote deals with headers that have the same name, not headers that have different names. Regarding headers that have different names the spec says " The order in which header fields with differing field names are received is not significant."
Nope, nevermind, I misinterpreted your bug report and the test case you provided.
Thank you, this has been merged to master.
Waitress 0.8.8 is out with this fix.