Re: Declarative HTTP Spec Test Suite

[Daniel Stenberg <[e-mail]>]

On Mon, 27 May 2024, Mohammed Al Sahaf wrote:

> I hear you. But how do you reconcile the need to mimic non-compliant 
> behavior with behavior that varies across different agents?

Either we go with what we believe is the behavior that makes the most sense 
for our users, or in some unfortunate cases we add an option that pushes the 
decision to the user.

Like curl has the --ignore-content-length option to ignore for example 
negative Content-Length: headers. As some might remember, in the late 90s and 
early 00s it was not uncommon for HTTP/1 servers to respond with negative 
Content-Length: on "large files" and we had users who still needed to get the 
contents off such servers in spite of their obviously wrong header field 
contents.

> I also wonder what other areas are there differing behavior as this case and 
> what could be the impact, though they're likely edge-cases because no one 
> complained loudly yet.

I'm convinced every HTTP implementation has such areas as well as the things 
we fixed because someone complained loudly within our respective projects, but 
those shouts never triggered a later HTTP spec update. Or we fixed issues in 
one way twenty years ago and then later we updated the specs to say something 
marginally different than our original fixes did but we have not gone back and 
fixed the implementation since...

> I believe it'll be valuable to know the situations of "This is where X 
> differs from {the rest, RFC}". Maybe it's a bug in the implementation. Maybe 
> it's not an oversight, rather the devs have a good reason for sidestepping 
> that part of the spec. Maybe it's a bug in the spec. What I hope to achieve 
> with this is to shine a spotlight on the various implementations to find 
> those dark corners. It'd be like the [Can I Use](https://caniuse.com/) 
> comparison table.

I completely agree that it would be interesting and maybe even valuable.

It will certainly be helpful to any newcomers in the field.

-- 

  / daniel.haxx.se