Re: Declarative HTTP Spec Test Suite

[Daniel Stenberg <[e-mail]>]

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