- From: Daniel Stenberg <daniel@haxx.se>
- Date: Mon, 27 May 2024 15:43:38 +0200 (CEST)
- To: Mohammed Al Sahaf <mohammed@caffeinatedwonders.com>
- cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
- Message-ID: <6758o6r-8962-5nnq-q18p-59o7q9177rno@unkk.fr>
On Sun, 26 May 2024, Mohammed Al Sahaf wrote: > - Firefox fails the transfer on plaintext HTTP with > "NS_ERROR_NET_PARTIAL_TRANSFER"; but with HTTPS connection, it only reads > and displays payload per the number of bytes stated in the header value. As the lead developer of curl, I have found it easier to make curl be stricter than the browsers in some these areas - probably partly because we did it so from the beginning. But also: authoring a toolset that is often used to mimic or reproduce what a browser can do, we occasionally have to sacrifize spec compliance in order to allow the users to do exactly this. To rather mimic someone else's (non-compliant) behavior because that is what users expect. Because that's how the Internet works now. (Like in the case of URLs.) > The first challenge is to find an HTTP client that implements HTTP Semantics > RFCs perfectly, otherwise its own idiosyncrasies will get in the way of the > validation. One would be tempted to default to curl, especially that hurl > uses curl under the hood. However, there is a chance curl may have its ownn > set of HTTP idiosyncrasies that may affect the results of the test > execution. Changes to curl are probably not desired unless the subject > behavior is confirmed to be a defect. Involvement of curl is voluntary to > curl, and the team may be looped and involved into this initiative for > comments if desired. It is not really in curl's interest to reach a highscore in a compliance test if that means that it interoperates less good. curl is not a HTTP compliance meter, it is an internet transfer tool and library. This said, we of course want to comply as far as possible, but whenever there is a fork in the road, the decision might not always be to go with the strictest language in the most recent RFC. I'm also sure we can find downright bugs or just protocol silliness even in curl's implementation. Also, as has been discussed numerous times: the HTTP RFCs mostly describe how things should work and how to behave, not how to act when the other side does the wrong thing or how to fail etc. -- / daniel.haxx.se
Received on Monday, 27 May 2024 13:43:44 UTC