beneroth changed the topic of #picolisp to: PicoLisp language | The scalpel of software development | Channel Log: | Check for more information
genpaku has quit [Ping timeout: 250 seconds]
genpaku has joined #picolisp
seninha has quit [Quit: Leaving]
lagash has quit [Quit: ZNC -]
lagash has joined #picolisp
lagash has quit [Quit: ZNC -]
lagash has joined #picolisp
<abu[m]> I think fbytez's problem yesterday was that he confuses two different things: "wrong data" with "harmful data"
<abu[m]> Absurdely long http headers or illegal bytes in the stream are wrong, but not per se harmful
<abu[m]> General DDOS attacks may be harmful, but they cannot be fixed by just limgting header line lengthes
<abu[m]> And on the other hand data can always be wrong on many levels. There is no low-level fix.
<aw-> HTTP header length is not specified in HTTP/1.1 RFC
<aw-> i set mine to 8192 Bytes
<abu[m]> Hi aw-! OK, but fbytez wants to limit the *length* of each line in the header to some arbitrary value.
<aw-> that doesn't even make sense
<aw-> at least for HTTP it makes no sense
<abu[m]> and also gives no safety against DDOS attacks
<aw-> yeah.. i guess one of HTTP's failings is that it doesn't specify these limits, so people just do whatever and somehow things work
<abu[m]> On the other hand, long lines are not a problem for Pil, as it uses no buffers of a certain length
<aw-> well
<aw-> you can't do it in HTTP anyways
<aw-> HTTP/1.1
<aw-> "A server MUST NOT
<aw-> apply a request to the target resource until the entire request header section is received"
<aw-> technically an RFC compliant server would receive/parse ALL the headers, and then process the request
<abu[m]> I see
<aw-> so to apply a limit per header line length makes no sense
<aw-> although i'm not against the idea of limiting the total size of ALL headers combined
<abu[m]> OK to save memory and bandwidth
<abu[m]> Obove some size it is probably no legal header
<abu[m]> But memory and bandwidth may as well be stressed by the transaction payload and not the header
<abu[m]> So I would not focus on the header
<aw-> and this is HTTP/1.1 btw, i think in HTTP/1.0 this is not specified either:
Regenaxer has joined #picolisp
<aw-> by the way, this SO answer provides some insight on what other web servers do:
<aw-> "For most servers, this limit applies to the sum of the request line and ALL header fields"
<aw-> nginx: 4K - 8K
<aw-> Apache: 8K
<abu[m]> Good to know
<aw-> nobody imposes a limit per header
lagash has quit [Quit: ZNC -]
lagash has joined #picolisp
rob_w has joined #picolisp
lagash has quit [Quit: ZNC -]
lagash has joined #picolisp
Regenaxer has left #picolisp [#picolisp]
Regenaxer has joined #picolisp
lagash has quit [Quit: ZNC -]
lagash has joined #picolisp
Regenaxer has left #picolisp [#picolisp]
Regenaxer has joined #picolisp
lagash has quit [Quit: ZNC -]
lagash has joined #picolisp
lagash has quit [Quit: ZNC -]
lagash has joined #picolisp
Regenaxer has left #picolisp [#picolisp]
<beneroth> aw-, abu[m] well a webserver can chose to impose a limit on headers and respond with HTTP 431 Request Header Fields Too Large
<beneroth> which can mean the total length was over limit, or a single header was over the limit, its not clear. up to the webserver.
<beneroth> I've never saw it anywhere :D
Regenaxer has joined #picolisp
<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.
<abu[m]> yep
Regenaxer has left #picolisp [#picolisp]
Regenaxer has joined #picolisp
lagash has quit [Quit: ZNC -]
lagash has joined #picolisp
lagash has quit [Quit: ZNC -]
lagash has joined #picolisp
lagash has quit [Quit: ZNC -]
clacke has quit [Read error: Connection reset by peer]
seninha has joined #picolisp
lagash has joined #picolisp
lagash has quit [Quit: ZNC -]
lagash has joined #picolisp
lagash has quit [Quit: ZNC -]
lagash has joined #picolisp
avocadoist has quit [Ping timeout: 252 seconds]
rob_w has quit [Quit: Leaving]
<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
lagash has quit [Quit: ZNC -]
<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
lagash has quit [Quit: ZNC -]
<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
<beneroth> @ pissing people off:
avocadoist has joined #picolisp
<beneroth> full linux distros running in light bulbs were just a horrible idea.... but economical feasible I guess
casaca has joined #picolisp
payphone has joined #picolisp
<aw-> haha nice XKCD, old one
<beneroth> there is an XKCD for everything :D
<beneroth> you're doing night work?
<aw-> no, about to go to sleep
<aw-> ;) ;)
<aw-> see you beneroth, always a pleasure discussing with you
<beneroth> same, have a good night :)
seninha has quit [Quit: Leaving]
casaca has quit [Remote host closed the connection]
payphone has quit [Remote host closed the connection]
payphone has joined #picolisp
casaca has joined #picolisp
Regenaxer is now known as abu
abu has left #picolisp [#picolisp]
abu[7] has joined #picolisp
abu[7] has left #picolisp [#picolisp]
abu[7] has joined #picolisp
<abu[7]> Test
<abu[m]> Good!
seninha has joined #picolisp
seninha has quit [Remote host closed the connection]
seninha has joined #picolisp
lagash has quit [Quit: ZNC -]
lagash has joined #picolisp
seninha has quit [Ping timeout: 240 seconds]
inara` has quit [Quit: Leaving]
seninha has joined #picolisp
seninha has quit [Ping timeout: 240 seconds]
inara has joined #picolisp
seninha has joined #picolisp
clacke has joined #picolisp