-
Notifications
You must be signed in to change notification settings - Fork 178
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
only sort the headers by key not by value #44
Conversation
--HG-- 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. |
Testing comes to mind, when output matters |
I found another place that manipulates the headers. |
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. |
great thanks |
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.