IRCaBot 2.1.0
GPLv3 © acetone, 2021-2022
#saltr
/2024/02/15
~dr|z3d
@RN
@RN_
@StormyCloud
@eyedeekay
@postman
@zzz
%Liorar
+FreefallHeavens
+Xeha
+bak83_
+cumlord
+hk
+poriori
+profetikla
+uop23ip
Arch
DeltaOreo
FreeRider
Irc2PGuest10850
Irc2PGuest19353
Irc2PGuest23854
Irc2PGuest46029
Irc2PGuest48064
Meow
Nausicaa
Onn4l7h
Onn4|7h
Over
T3s|4__
acetone_
anon4
anu
boonst
enoxa
glowie
mareki2pb
mittwerk
orignal
plap
shiver_
simprelay
solidx66
u5657_1
weko_
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!