IRCaBot 2.1.0
GPLv3 © acetone, 2021-2022
#saltr
/2024/02/15
~dr|z3d
@RN
@RN_
@StormyCloud
@T3s|4_
@eyedeekay
@orignal
@postman
@zzz
%Liorar
+FreefallHeavens
+Leopold
+Xeha
+acetone
+bak83_
+cancername
+cumlord
+hk
+profetikla
+uop23ip
+weko
An0nm0n
Arch
Danny
DeltaOreo
DrSekra
Irc2PGuest28769
Irc2PGuest3160
Irc2PGuest63086
Irc2PGuest71439
Meow
Nausicaa
Onn4l7h
Onn4|7h
Over1
anon
anu3
boonst
carried6590
chatrouge
enoxa
mareki2pb
plap
poriori_
shiver_
simprelay
solidx66
tr
u5657
dr|z3d zzz, might be wrong, but this chunk of code looks like it's missing a closing brace:
dr|z3d long afterHandle = getTunnel().getContext().clock().now();
dr|z3d if (requestCount == 0) {
dr|z3d long timeToHandle = afterHandle - afterAccept;
dr|z3d getTunnel().getContext().statManager().addRateData("i2ptunnel.httpserver.blockingHandleTime", timeToHandle);
dr|z3d if ((timeToHandle > 1500) && (_log.shouldLog(Log.WARN))) {
dr|z3d _log.info("[HTTPServer] Took a while (" + timeToHandle + "ms) to handle the request for " + remoteHost + ':' + remotePort +
dr|z3d "\n* Client: " + peerB32 +
dr|z3d "\n* Tasks: Read headers: " + (afterHeaders-afterAccept) + "ms; " +
dr|z3d "Socket create: " + (afterSocket-afterHeaders) + "ms; " +
dr|z3d "Start runners: " + (afterHandle-afterSocket) + "ms");
dr|z3d either that or the indenting isn't right.
dr|z3d ~line 657 in I2pTunnelHTTPServer.java
dr|z3d nevermind, my mistake.
dr|z3d minor type later on: Read a line teriminated by newline
tennis2 dr|z3d> Sorry for late response, to be fair I was only defending my position from "conspiracy shaming". I'm going to stay on the alert personally. Finding up to date lists of oracle and akamai ip addresses is proving more difficult than I expected it to be, I'm interested in testing i2p without them, to see if the problems go away.
zzz javadoc typos (from 2015) fixed, thx
dr|z3d tennis2: if you don't like ips, add them to your blocklist.
dr|z3d no worries, zzz.
dr|z3d a couple of questions for you re keepalive. a) is it enabled for zzz.i2p and b) shouldn't I be seeing keepalive headers in the browser console if it is?
dr|z3d I *think* I've seen it working on git.skank.i2p selectively.. if I manually configured the keep-alive timeout on the server it shows that in the keepalive column of firefox's network console.
zzz dr|z3d, a) yes
zzz b) is harder
zzz - keepalive is the default for http/1.1
zzz - since it's the default there isn't really a "keepalive header".
zzz you could see Connection: keep-alive, but probably not, just look for the absence of Connection: close
zzz BUT
zzz remember that each hop is independent
zzz so the browser-to-proxy hop could be (is) keepalive even if the i2p hop, or the server, isn't. That was the client-side changes
dr|z3d ok, thanks for the clarification.
zzz how are you 'manually configuring keepalive timeout on server'?
dr|z3d I was messing about with keepalive timeout headers.
zzz in e.g. nginx? or in our source static final values?
dr|z3d nginx
dr|z3d e.g. add_header Keep-Alive 'timeout=60s';
zzz that's not going to do anything
zzz hmm, not familiar with that header
dr|z3d it should, it should override the timeout set in httpserver.
zzz the header is Keep-ALive: ? or Connection: Keep-alive timeout=60s?
dr|z3d if you enable that in nginx, it'll show up in the network console under the keep-alive column.
dr|z3d the former.
zzz hmmm
dr|z3d if you want to explicitly enable keep alive headers, that's differnt.
dr|z3d > add_header Connection 'Keep-Alive';
zzz not sure we want to let that thru
zzz as far as nginx knows there is no keepalive. We don't do keepalive for the server hop
zzz so our server side proxy splits up every keepalive request to a new socket to nginx
dr|z3d ok, well those headers aren't currently enabled, I was just experimenting to see if I could see keepalive indicated in the network console.
zzz I think the only way to know for sure is logging I2PTunnelHTTPServer, but I'll think about it
dr|z3d we could send an X-I2P-KeepAlive header or something perhaps?
zzz I guess you could log at the client side and see also
zzz but the key concept is that this last checkin enables keepalive of the i2p socket, if both server and client proxies support it
zzz that's independent of either the server socket (not supported) or browser socket (always on after phase 1) keepalive
dr|z3d since we're on the subject of headers and logging, might be a good time to consider pruning those...
dr|z3d for example, do we really need both X-I2P-DestB32 and X-I2P-DestB64 both logged?
zzz gotta run, we can discuss later ))
dr|z3d aight, have fun!