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