#saltr (irc2p) | I2P+ 2.10.0-14+ >> i2pplus.github.io | skank.i2p | git.skank.i2p | purokishi.i2p | vituperative.github.io/i2pchat | notbob.i2p | ramble.i2p | drop.i2p | shinobi.i2p | wall.i2p | /msg an op for voice

uop23ip Hi. dr|z3d , why is the clearnet download of i2pplus http? The site is https.

dr|z3d you'll have to give me more context, uop23ip

dr|z3d typo/error

dr|z3d thanks, will fix.

uop23ip oh i see wget makes it to https

dr|z3d it should automatically redirect to https, notwithstanding, so the link should work.

dr|z3d you might want to download a dev build, uop23ip.

dr|z3d it's stable and it fixes a couple of minor issues. or you can just update to a dev build post-install.

uop23ip Will switch later. At the moment i am in the process of trying to install on android tv box with termux.

dr|z3d should work ok, I've installed on android via termux before without issue.

uop23ip done it before, too. Want to see if it is still doable :)

dr|z3d once you get it installed, let me know if there's anything sub-optimal in the display, given you're putting it on a tv.

uop23ip Blinded message

dr|z3d no, it won't. there's no wrapper support, so runplain

dr|z3d unless you feel like messing around with the tanuki wrapper and seeing if you can get that to work.

uop23ip error: Unable to locate "ps" lol. But it is there

uop23ip runplain works

uop23ip woah

uop23ip it wants to open a browser and ask me which.

uop23ip nice :)

snowflakes dr|z3d, hewwo friend

snowflakes are u here?

dr|z3d hi snowflakes

dr|z3d all good over there?

snowflakes almost some troubles in own life but all pass good

snowflakes someones want to know about stormycloud and purokishi

dr|z3d oh, pass good sounds like the right answer. try not to do an acetone, eh? :)

snowflakes why i will dont use acetone or dont do acetone i dont understood if true

snowflakes So, i dont yet get out from russia

dr|z3d oh, not good. but not conscripted?

dr|z3d re acetone, I meant try not to get sent to the gulag :)

snowflakes i just dont going to them killers

snowflakes ok got it thanks you about that

snowflakes just ignoring them

snowflakes they forgot me and them. I use subconscious techniques

dr|z3d if you can get out of the country, all the better.

snowflakes do what ports on purokishi socks/http proxy (destinationport)?

snowflakes i understand but i dont sure about my family

snowflakes i have money for that

snowflakes for going to kazahstan

snowflakes you think i would go to kazahstan and found there a work

snowflakes oh do u see antebeot.world/antebeot.i2p?

dr|z3d purokishi is a dest, doesn't matter what local port you use, normally :4444

snowflakes them want destination port, them use though i2pd. there is options (destinationport)

snowflakes if this destinationport dont exists using

dr|z3d not seen, no. dunno about kazakstan, but if you can code, doesn't really matter where you are if you can find work.

snowflakes main port of server. i see a some agression/or violation of divine law. must be silent of a while

dr|z3d if you need to specify a port, try 80.

dr|z3d let me know if it works for you.

dr|z3d (or your ilita buddies)

snowflakes got it

dr|z3d *thumbs up*

snowflakes yeap

snowflakes inshabluhbluhbluh

snowflakes We have xmpp servers. There i have good avatar of unabomber

snowflakes Do u know about FRN? FreeRadioNetwork

dr|z3d not really. what's that about?

snowflakes There is repeaters (radio, on the freee diapasons) for talks though PCs/Phones

dr|z3d sounds like chaos :)

snowflakes I can to talks to radio diapasons though PC and this is legal

snowflakes almost

snowflakes there is moderators

snowflakes them block something moments

snowflakes also i have for a now RTL_SDR and will get an another one

snowflakes and KW180Wla

snowflakes k180wla*

snowflakes will public access to this for a public and though i2p

snowflakes will be better if i set up antenna dont at "windows-out room "

snowflakes in someone another places but there not electricity

snowflakes so got it about port 73 thanks

snowflakes about war moments there is all bad

snowflakes i have a friend that killer of people and him talks about this that all tired

dr|z3d port 73?

snowflakes dont. 73 is mean about nice to meet you+ have a good luck + have a good day + nice to meet you + etc

snowflakes in radio diapasons

dr|z3d oh. my bad.

dr|z3d 10-4

snowflakes 10-4 i think is police code

snowflakes i played in samp in ROlePlay server where i was policeman

snowflakes and i say 10-4 to teamspeak as code when i accept message

dr|z3d 10-4 is used in various places.

snowflakes got it

dr|z3d I'm looking at the http client code, zzz.

dr|z3d It appears we're not allowing brotli compression which seems like an oversight.

dr|z3d > allowGzip = lowercaseLine.contains("gzip");

dr|z3d can't we just change that to allowGzip = lowercaseLine.contains("gzip") || owercaseLine.contains("br");

dr|z3d or maybe something like this:

dr|z3d // strip the accept-blah headers, as they vary dramatically from

dr|z3d // browser to browser

dr|z3d // But allow Accept-Encoding: gzip, deflate

dr|z3d if (lowercaseLine.startsWith("accept-encoding: ")) {

dr|z3d allowGzip = lowercaseLine.contains("gzip") || lowercaseLine.contains("br");

dr|z3d line = "Accept-Encoding: gzip, deflate, br";

zzz dr|z3d, the code you reference does not modify or strip the accept-encoding header

zzz however your change does, and not in a good way

dr|z3d yeah, trying to work out where in the code we're not accepting br.

dr|z3d this I know, having tested it :)

dr|z3d at least the server can send br encoded content now.

dr|z3d that's the plus side.

dr|z3d on the minus side, the client now just sees the encoded content as garbage. :)

dr|z3d Server side: Content-Encoding: br (good)

dr|z3d Client side: Accept-Encoding: gzip, deflate (bad)

dr|z3d If I try Tor browser for comparison, it's sending the correct response headers for br: Accept-Encoding: gzip, deflate, br

dr|z3d the only other thing that looks like it might be preventing brotli encoding is this? if (!usingInternalOutproxy)

dr|z3d newRequest.append("X-Accept-Encoding: x-i2p-gzip;q=1.0, identity;q=0.5, deflate;q=0, gzip;q=0, *;q=0\r\n");

zzz no

zzz x-a-e != a-e

dr|z3d ok, didn't think so, but wanted to check.

dr|z3d so any clues as to where else we might be preventing brotli from doing its thing?

zzz i suggest you log headers on the server, or in I2PTunnelHTTPServer, to prove or disprove your theory that the header is being altered (assumping you've already proven the browser is sending it via netwok console)

dr|z3d server's sending br encoded content when permitted.

dr|z3d client is sending 'accept-encoding: gzip, deflate' header which is the issue.

zzz you've proven the browser is sending br and the http client side proxy is changing it?

dr|z3d the server's sending br when permitted, the browser won't replay br content unless the headers are correct.

dr|z3d *relay

dr|z3d if I send a curl requests directly to the server on localhost, it responds with br encoding.

zzz so you're saying br is requested by browser, br is sent by server, but it's not being rendered due to some _response_ header being incorrect?

dr|z3d correct.

dr|z3d the response header is: accept-encoding: gzip, deflate

zzz no. accept-encoding is a REQUEST header

dr|z3d the response header should be accept-encoding: gzip, deflate, br

dr|z3d so, request header.

dr|z3d *sorry

zzz we can't get very far here without getting the two drirections straight ))

dr|z3d :)

dr|z3d server end of the deal appears to be fine.

zzz if the REQUEST header does not contain br, then the RESPONSE will not be br-encoded

dr|z3d so we can rule that out.

zzz yet you say the response IS br encoded?

zzz or that we are stripping br from the request header?

zzz or what?

dr|z3d it is at the moment, because I've foobared the headers. forget that. the issue is that the accept-encoding REQUEST headers don't include br, so normally the server's not sending br encoded content.

dr|z3d so it appears we're stripping or otherwise mangling the request headers to remove br, yes.

zzz have you verified via the browser network console that it is sending br?

dr|z3d >> if I send a curl request directly to the server on localhost, it responds with br encoding.

zzz that doesn't answer the question

dr|z3d if I mangled the request headers as per above, then it also sends br. so it's NOT a server issue.

zzz in your test where the response was NOT br, did you verify that br was requested by the browser or curl

dr|z3d where the response was not br in the browser, the request header didn't include br in the accept-encoding header.

zzz -> not a bug then

zzz if the browser doesn't support br or doesn't ask for it, what would you have us do?

dr|z3d the browser supports br.

dr|z3d I'm using LibreFox, might as well be Firefox, same difference. And Tor Browser's sending the correct request headers.

zzz but it didn't ask

dr|z3d *LibreWolf

zzz <dr|z3d> ... the request header didn't include br in the accept-encoding header.

zzz no accept br, no get br back

dr|z3d yup, in LibreWolf. in TorBrowser, the correct accept-encoding headers are present. And yes, I get that part, I'm just trying to work out where or if we're (I2P) flitering br from the accept-encoding header.

dr|z3d stackoverflow confirms firefox/librewolf should be sending the following request headers: "When using the latest versions of Chrome and FF, in all cases, the https request header has the following token: Accept-Encoding:gzip, deflate, br"

zzz logging in i2ptunnel will quickly tell you headers in/out

dr|z3d ok, I think I might have discovered something, thanks for your patience.

dr|z3d it's the usual browser bullshit games.

zzz but I again ask if you've verified via browser network console (not stack overflow)

dr|z3d in firefox we have 2 configs: network.http.accept-encoding and network.http.accept-encoding.secure

dr|z3d and guess what the difference is?

dr|z3d I'll give you a hint.. 2 letters and a comma..

dr|z3d via the network console, I was only seeing accept-encoding: gzip, deflate for all .i2p requests

dr|z3d it appears br encoding is intentionally disabled for http.

dr|z3d (in firefox)

dr|z3d my incorrect assumption from a wrong read of the http client code was that we were somehow stripping out br encoding. sorry to waste your time.

dr|z3d ok, confirmed. if I add br to network.http.accept-encoding in firefox, I'm correctly receiving content br-encoded over i2p.

zzz yeah best practice try to prove a theory and isolate where it's happening before trying to fix it ))

dr|z3d :)

dr|z3d at least we learnt something today.

dr|z3d firefox disables brotli over http by default.

zzz my guess would have been it disables it thru proxies by default

zzz i wonder why

dr|z3d yeah, well, I'm not sure I see the logic in disabling over http, maybe it's a "you should really be using https, no one running a webserver on http needs this"

dr|z3d if you want to test a brotli-enabled server, git.skank.i2p is now brotli-enabled.

snex 🥦.i2p