~dr|z3d
@RN
@StormyCloud
@T3s|4
@T3s|4_
@eyedeekay
@orignal
@postman
@zzz
%Liorar
+FreefallHeavens
+RTP
+Unbur
+Xeha
+acetone
+cumlord
+j6
+profetikla
+r00tobo_BNC
+snex
+uop23ip
+weko
An0nm0n
Arch
Danny
DeltaOreo
DiCEy1904
Irc2PGuest43975
Irc2PGuest48909
Irc2PGuest67564
Irc2PGuest91332
Onn4l7h
anon2
anontor
anu
bak83
boonst
fujifilm
goose2
goose2_
itsjustme
mareki2pb
not_bob_afk
onon_1
poriori_
qend-irc2p
shiver_
thetia
u5657
unwr
veiledwizard
xen_NULL
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!