~dr|z3d
@RN
@T3s|4
@T3s|4_
@eyedeekay
@orignal
@zzz
+Hikari
+Minogami
+Xeha
+acetone
+profetikla
+snex
+uop23ip
+weko
An0nm0n
Arch
DeltaOreo
FreefallHeavens
Gid
Irc2PGuest13871
Irc2PGuest2974
Leopold
Liorar_
Nausicaa
Onn4l7h
StormyCloudInc
admin
anon
anontor
anu
cheddah
itsjustme_
j6
limak
not_bob_afk
poriori_
qend-irc2p_
u5657
dr|z3d
dang, zzz, you been busy on that.
dr|z3d
how robust is persistence right now? what's your confidence level that it works without breaking things?
T3s|4
lols RN - with 57+ running well, each passing hour increases the probability we will again achieve the rarefied nirvana of the 60s :D
RN
oi T3s|4, been a while since I updated... you are well ahead of me
T3s|4
np RN, but 57+ appears to be running solidly
RN
Yeah, I have good reason to try a newer version... Just a small thing I need to set up first and I'll give 57+ a go.
RN
spent several hours waitnig for that small thing to finish, and am passing the time refining file://usr/RN/links.html
dr|z3d
thanks for the persistent connections code, zzz, appears to be working a.ok
dr|z3d
after some testing, it's now deployed in + dev builds.
dr|z3d
also, re http/2, already works fine on the outproxies for sites that have it.
dr|z3d
T3s|4: happy to hear things are running well in -57+. a couple of minor issues still to resolve for snark, but mostly it should be fine.
dr|z3d
> thanks for the persistent connections code, zzz, appears to be working a.ok
dr|z3d
> after some testing, it's now deployed in + dev builds.
dr|z3d
> also, re http/2, already works fine on the outproxies for sites that have it.
zzz
dr|z3d, robustness: intended to be high, but... confidence: low, because it needs testing with a wide variety of browsers/clients, servers, and request types/traffic
zzz
for example, I haven't tested news/addressbook/update fetches thru it, and if it breaks that it would be catastrophic
dr|z3d
that's all eepget, should be easy to confirm it works.
dr|z3d
keep-alive headers enabled on git.skank.i2p if you want to test it there. you can see keep-alive headers in the firefox developer panel under networking if you turn on that column.
zzz
remember this is hop-by-hop
zzz
this is 'phase 1' - the browswer socket. You can't do anything on the server side to make it "more keepalive"
dr|z3d
you can send keep-alive headers. whether they make any difference or not is a different matter.
zzz
http/1.1 is keepalive by default. See RFC 2616
zzz
we override that by injecting connection: close at every hop, because we don't support it
zzz
the patch changes the client side proxy. no changes to the server side proxy
dr|z3d
yeah, noticed you were doing it one stage at a time.
zzz
connection: keepalive is for HTTP/1.0 (which is non-persistent by default), and not worth dealing with
dr|z3d
yeah, sure, agreed.
dr|z3d
eepget works fine, so I can't see there being an issue with news/updates/subscriptions.
zzz
sure, but hope is not a test plan :)
dr|z3d
I'll let you know when I see confirmation log events in my wrapper logs.
dr|z3d
(for addressbook subs)
dr|z3d
ok, zzz, your hunch regarding addressbook subs and updates may well be right.
dr|z3d
unsigned updates definitely borked with your keepalive code, and it looks like subscriptions is as well.
zzz
thanks dr|z3d I'll try to reproduce; any details on exactly how it fails?
dr|z3d
nothing in the logs, but unsigned updates get a "cannot connect" error.
dr|z3d
that happens even on the router hosting the update.
zzz
ok
dr|z3d
eepget works fine with the same url.
zzz
found it, super dumb bug
dr|z3d
that was quick, well done.
zzz
poorly done, but never claimed to be immune from it :)
dr|z3d
:)
dr|z3d
we're squashing bugs before the code's even been merged, so don't be too hard on yourself :)
zzz
dr|z3d, two-liner fix tested and pushed to the branch/MR 129