<beneroth>
I agree with your general notion. He just felt in love with the rules and theory and overlooked their purpose, that they are just helpers to get the purpose implemented but useless without the purpose. widespread mistake in theory-loving programmers. see also XML, UML, etc.
<aw->
beneroth: yeah that's exactly what i said... and most web servers out there use the length of all headers combined as their heuristic, rather than the length of a single header
<aw->
anyways it makes no sense to check the length of EVERY header line
<aw->
it's such un-necessary overhead
<Regenaxer>
T
<aw->
which is probably why none of the popular webserver software does it
<aw->
i have to admit the HTTP RFCs are difficult to grok and there's lots of vague statements, but you don't even need to read the RFCs to realize why fbytez plan was not good
lagash has joined #picolisp
<beneroth>
compared to what? I find RFCs is something of the most readable and clear descriptions of a tech. it's sometimes a bit dense, true, as is pil documentation. but its very clear when reading focused.
<aw->
beneroth: no, you have clearly never read the HTTP/1.1 RFCs
<aw->
i dare you to read them and try to implement an RFC compliant HTTP server
<beneroth>
I wonder why not more programmers actually read that stuff. other kinds of requirements we get (esp. in business settings) are nearly always way more ambiguous and full of gaps.
<aw->
get back to me in 3 months after you finish smashing your head
<beneroth>
I've read them.
<beneroth>
it's a bit more distributed over multiple RFCs than with other RFC standards, okay...
<aw->
yes there's like 5 different documents
<beneroth>
yeah thats ugly
<aw->
RFC 7230-7235
<beneroth>
I think the email RFCs are more of a mess, though I haven't read them fully, so cannot tell for sure
<aw->
yeah i already read RFCs, so much good stuff in there
<beneroth>
we are lucky that RFCs are out in the public and mostly quite attainable
<beneroth>
compared with electronics or machine engineering standards
<aw->
what
<aw->
electronics and mechanical engineer have much more strict and published standards than software
<aw->
and well written
<aw->
the only problem is each country implements their own hahahhaa
<beneroth>
yeah. and all pay-walled.
<aw->
you're talking about ISO standards?
<beneroth>
ISO, JIS, IEEE, ...
<aw->
yeah... you can't really compare internet RFCs and ISO standards
<beneroth>
you mean because... ISO standards etc. are actually checked by certification bodies?
<aw->
the internet RFCs have always been more informal, definitely easier to read, but so much vague and unspecified stuff that we end up with 20 different open source web servers which all behave differently
<beneroth>
true, the ideal thing would be one single definite open source web server implementation.
<beneroth>
but then again, NIH.
<aw->
ISO standards are almost intentionally verbose and precise to the point of eye bleeding, specifically to avoid mis-interpretations
<aw->
maybe there's some + and - for both... it would be curious to see how software would be if it were all governed by ISO standards instead of ad-hoc implementations of internet RFCs
<beneroth>
yeah that discussion is still open. though the worries are that making certification mandatory for software would probably just end up as in medicine tech... where the cost of certification is substantial and then you leave the tech on old vulnerable versions because updating requires costly re-certification
<beneroth>
one benefit of the public RFCs is that there are more eyeballs. while the IEEE (e.g. WLAN, bluetooth) standards are less well researched by security people, so when someone actually checks the vulnerabilities are often quite devastating
<beneroth>
I'm also not so sure if the many software implementations is really up to the missing/unclear specifications in the RFC or not more often just a product of NIH and just sloppiness
<aw->
beneroth: yeah you nailed it
<aw->
very much sloppiness
<aw->
lazyness
<aw->
a lot of people don't read the RFCs fully, multiple times, before/during implementing
<beneroth>
T
lagash has joined #picolisp
<beneroth>
sometimes the RFCs are also stupid and we kinda came to hive-mind-consensus to ignore them. but then the RFC should be updated
<aw->
but this HTTP headers thing is proof of the RFC missing information: they don't specify limits and don't make it mandatory, so "it's up to the implementation" which leads to lots of different things that don't always work well togete
<aw->
together*
<beneroth>
e.g. local part of email adresses (the part before the @) are supposed to be case-sensitive.. I'd like to test that once when I have too much time, I bet this will not come through most email processing servers :)
<beneroth>
aw-, true
<aw->
haha yeah like IPv6 RFC.. i really wish they update that
<beneroth>
what's up with the IPv6 RFC? I didn't dare to dive into that yet
<beneroth>
the thing with HTTP header.. usage and requirements may vary, and resources may also very depending on implementation. so I guess that's way its very open. the alternative would be many more HTTP versions. or multiple subversions for different header formats (well that would be sensible)
<aw->
IPv6 RFC specifies dual-stacking, in that both IPv4 and IPv6 can co-exist
<beneroth>
then again a open standard with much undefined behavior is vulnerable to capture by whoever party to gets some nice features in it, distributes it broadly, but somehow can keep others out.
<beneroth>
e.g. as in HTML, I think W3C is now largely a joke just standardizing whatever Chrome rolled out 6 months ago
<aw->
and because these two protocols can co-exist on the same network, we will literally **never** reach 100% IPv6 adoption
<beneroth>
IPv6 oh yeah.. but not having one standard for how they should co-exist
<aw->
they should have deprecated IPv4
<beneroth>
well for all practical purposes the IPv6 internet is physical separate from the IPv4 network, no?
<aw->
"switch to IPv6 by January 1, 2001 or get cut off from the internet"
<aw->
done
<beneroth>
well for that you would need the majority of ASNs to agree on anything
<beneroth>
otherwise you just end up with multiple internets
<aw->
yes and i'm pretty sure in 2001 it was much more feasible than in 2023
<beneroth>
well that's true, haha
<aw->
now we're completely fucked
<aw->
and computers **must** support both
<beneroth>
no worries, we will find ways to make it even worse
<aw->
which is the big problem, support one or the other is perfectly fine, but supporting both simulatenuously is a huge pain
<aw->
haha
<aw->
anyways these are difficult problems, the truth is there's no black/white solution to it
<aw->
you can write an RFC for something, deprecate something else, there will always be pissed off people
<aw->
and light bulbs that can't be turned off ;)
payphone has quit [Remote host closed the connection]
casaca has quit [Remote host closed the connection]
<beneroth>
it's because there is no absolute true/false, it's arbitrary decisions (sometimes based on well-thought-out trade-offs and/or physics, sometimes not so much). that's what people like fbytez often have trouble with, they look for the perfect truth.
<beneroth>
it's created primarily by human consent, not universal objective reality