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
KNOWN_BUGS cleanup #9871
KNOWN_BUGS cleanup #9871
Conversation
1.2 Multiple methods in a single WWW-Authenticate: header This is not considered a bug anymore but a restriction and one that we keep because we have NEVER gotten this reported by users in the wild and because of this I consider this a fringe edge case we don't need to support.
1.6 Unnecessary close when 401 received waiting for 100 This is not a bug, but possibly an optimization that *can* be done.
1.7 Deflate error after all content was received This is not a curl bug. This happens due to broken servers.
2.1 CURLINFO_SSL_VERIFYRESULT has limited support This is not a bug. This is just the nature of the implementation.
2.2 DER in keychain This is not a bug.
This is not a bug.
This is not a bug.
As for 1.2, it's not true that this has NEVER been reported |
Ah wow I clearly forgot about that: so wrong of me. It has been reported, but it is still such a very rare thing that I do not consider it a bug. |
okay, so whether something is a bug or not is not decided by if it works according to the RFC that even has an explicit example for this but by how many people report it? 😀 But sure, curl is free to sell it as "just not supported" :) It cost us many man hours and forced us to come up with an ugly workaround which is still in production today just to deal with this non-bug. I'd rather have spent a fraction of that sponsoring you or someone else to fix it. Unfortunately, that was not my decision to make :( |
Sort of, yes. It is now re-labeled as "a known implementation restriction", not a bug. It does not serve the project well to keep items in the known-bugs list that none of us intends to fix and that none of the project developers actually considers a bug. We need to stay pragmatic, we can never read or act on RFC specifications by their exact words only. curl does not live in a vacuum. This does not rule out that a future version of curl could have this auth header handling improved. |
It's tricky because the comma in WWW-Authenticate is used in the scheme as well as to separate schemes, which means you have to parse each scheme in order to know when the next scheme starts. You can see the code in Curl_http_input_auth does loop for multiple schemes but I guess it would need to be improved. Lines 1001 to 1139 in cd95ee9
Take your example
I would think in this case curl sends an Authorization for the first request, then if it gets this in reply: WWW-Authenticate: Negotiate, Basic realm="TM1" It assumes failure (data->state.authproblem = TRUE). Interesting it passes on I think he has a point that this should be in known bugs even if we aren't working on it. This is a known bug that libcurl does not handle multiple auth on the same line well, even though it may try (it does loop around, I don't know what good that does in cases with multiple options per scheme) |
A range of items mentioned in the document that I think are not actually bugs and thus do not belong therein.