~dr|z3d
@RN
@RN_
@StormyCloud
@eyedeekay
@postman
@zzz
%Liorar
+FreefallHeavens
+bak83_
+cumlord
+hk
+poriori
+profetikla
+uop23ip
Arch
DeltaOreo
FreeRider
Irc2PGuest10850
Irc2PGuest19353
Irc2PGuest23854
Irc2PGuest46029
Irc2PGuest48064
Meow
Nausicaa
Onn4l7h
Onn4|7h
Over
T3s|4__
Xeha
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
}
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!