~dr|z3d
@RN
@RN_
@StormyCloud
@T3s|4
@T3s|4_
@eyedeekay
@orignal
@postman
@zzz
%Liorar
+FreefallHeavens
+Xeha
+bak83_
+cancername
+cumlord
+hk
+profetikla
+uop23ip
Arch
DeltaOreo
FreeRider
Irc2PGuest19353
Irc2PGuest46029
Irc2PGuest64530
Meow
Nausicaa
Onn4l7h
Onn4|7h
Over1
acetone_
anon4
anu
boonst
enoxa
mareki2pb
mittwerk
not_bob_afk
plap
poriori_
shiver_
simprelay
solidx66
u5657_1
weko_
dr|z3d
zzz: you going to push that keepalive fix or can you paste the change here? :)
RN
zzz, I like the new 'unable to connect to update server ***' message! :)
T3s|4
RN: to your point, on both iterations of 57+ I running: ddc7b4ec (Build date: 2023-10-14 14:54:22 UTC)
T3s|4_
and on ea0195bf (Build date: 2023-10-14 04:15:01 UTC)
dr|z3d
T3s|4: note that until zzz patches his keepalive code, you'll need to manually update when running 57+, eepget works fine.
T3s|4
As soon as I check for updates, I see a static, permanent message of: Unable to connect to I2P+ update server skank.i2p
T3s|4
np dr|z3d
dr|z3d
yup, zzz's got that fixed, he just didn't tell me how he did it so I'm waiting for him to resurface :)
T3s|4
alrighty - let me know when the fixed patch is up on skank :)
dr|z3d
there's a new build up on skank, but if you're not hosting websites, there's nothing much new there right now.
dr|z3d
otoh, if you are hosting websites, we're stripping a lot more crud headers from the server response.
T3s|4
noted, thanks...
dr|z3d
jetty's default "visited=yes" cookie is also nuked. pointless.
zzz
<zzz> dr|z3d, two-liner fix tested and pushed to the branch/MR 129
zzz
somehow everybody missed that message
dr|z3d
oh, never noticed it, zzz, thanks.
zzz
check check is this thing on?
zzz
:)
dr|z3d
testing, testing, 1, 2, 3. mike check, affirmative.
dr|z3d
update available with zzz's fix, T3s|4. and anyone else.. running 57+ and you'll need to eepget the update .. i2p/eepget skank.i2p/dev/i2pupdate.zip
dr|z3d
here's a useful function for the httpserver tunnel to perform, zzz.. remove this header -> Expires: Thu, 19 Nov 1981 08:52:00 GMT
dr|z3d
expires is pretty much a waste of time if you have max-age set in cache-control, so I'm just removing that header if found, but if you want to be more selective..
dr|z3d
some context: thecustomizewindows.com/2015/01/remove-expires-thu-19-nov-1981-php-header-ubuntu-server
dr|z3d
found that while postman and I were tweaking his headers yesterday. I was scratching my head watching the php/html pages reload with an appropriate cache-control header set, and then I saw that. :|
dr|z3d
anyways, fix works, confirmed. unsigned updates are behaving as expected.
zzz
here's a question
zzz
I'm sending both a If-None-Match and If-Modified-Since to i2p-projekt for hosts.txt which matches the current content, but it's still sending the content back, not a 304
zzz
are we not supposed to send both or is the server doing something wrong
zzz
HTTPClient[1/1]: Line=[If-None-Match: "1696953602.24-49079-3078492705-gzip"]
zzz
HTTPClient[1/1]: Line=[If-Modified-Since: Tue, 10 Oct 2023 16:00:02 GMT]
zzz
HTTPResponseOutputStream: Response: HTTP/1.1 200 OK
zzz
HTTPResponseOutputStream: Response header [ETag] = ["1696953602.24-49079-3078492705-gzip"]
zzz
HTTPResponseOutputStream: Response header [Last-Modified] = [Tue, 10 Oct 2023 16:00:02 GMT]
zzz
since you're now a cache expert...
dr|z3d
is the e-tag varying with each request?
zzz
no
dr|z3d
something is, and tbh, that seems an awfully long winded way of just setting no-cache and a max-age.
zzz
as you can see above they match
zzz
it's not really about caching; it's saying only send it to me if it's newer
dr|z3d
newer than the copy you have in your cache?
zzz
addressbook saves the last-mod and etag from the previous fetch, then sends it in the next fetch
zzz
there is no "my cache"
dr|z3d
ok, gotcha.
dr|z3d
I think you should be good with just an e-tag. that's what I'm doing, and the server will happily send a 304.
zzz
can you test projekt with just an etag?
dr|z3d
e-tag and maybe last-modified as well.
dr|z3d
we don't have that subscription in the addressbook.
zzz
If both an entity tag and a Last-Modified value have been
zzz
provided by the origin server, SHOULD use both validators in
zzz
cache-conditional requests.
dr|z3d
too much junk in there.
zzz
so we're supposed to send both
dr|z3d
skank.i2p sends both afaik and it also responds with a 304 when talking to the addressbook.
dr|z3d
➤ Initiating eephead probe of skank.i2p/hosts.txt…
dr|z3d
• URL: skank.i2p/hosts.txt
dr|z3d
• Server: nginx (?)
dr|z3d
• Status: 200 OK
dr|z3d
• Content-Type: text/plain; charset=utf-8
dr|z3d
• Content-Length: 80189
dr|z3d
• Last-Modified: Tue, 22 Aug 2023 02:03:46 GMT
dr|z3d
• Etag: "64e41782-1393d"
dr|z3d
• Cache-Control: private, no-cache, max-age=604800
dr|z3d
• Accept-Ranges: bytes
dr|z3d
• X-Content-Type-Options: nosniff
dr|z3d
• X-FrameOptions: SAMEORIGIN
dr|z3d
• Content-Security-Policy: default-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data:; script-src 'none'; form-action 'self'; frame-ancestors 'self'; object-src 'none'; media-src 'none'
dr|z3d
• X-XSS-Protection: 1; mode=block
zzz
can you check if the 304 is currently working on skank?
zzz
projekt is on apache so it's not a jetty thing
dr|z3d
working fine.
dr|z3d
304s all over my logs.
dr|z3d
[15/Oct/2023:09:47:51] [304] [skank.i2p]/hosts.txt [Wget/1.11.4] 0 [krurjd]
dr|z3d
that was just the last request that came in, i2pd on account of the user-agent by the looks of things. but there's hundreds of 304s in the logs.
zzz
ok thanks
zzz
guess it's something on our server
zzz
maybe something with the gzip
dr|z3d
maybe don't bother gzipping it and let the server handle that on the fly?
zzz
it is
zzz
maybe this is it: Response header [Vary] = [Accept-Encoding]
zzz
but we're sending Accept-Encoding: gzip
dr|z3d
could be. less is more, header-wise :)
dr|z3d
last modified, no-cache and e-tag should be plenty.
zzz
ok if I take the -gzip off the end of the etag I get a 304
dr|z3d
great
zzz
so it's something to do with that
dr|z3d
if that's the solution, just do that. but those if-none-match headers seem like they can be given the boot as well.
zzz
no, etags are to be treated as opaque
zzz
and etags are "stronger" directives than last-mod
dr|z3d
you're not losing them, you're just losing the -gzip suffix.
dr|z3d
which adds nothing of value anyway.
zzz
it's opaque, it's not our business what's in the etag
zzz
it's an apache bug
dr|z3d
well something's generating that suffix, probably apache, so you can probably tell it not to.
dr|z3d
or it's doing that because of your vary header.
zzz
no
zzz
the vary header is from apache
dr|z3d
yeah, right, I'm saying tell apache not to send that.
zzz
that's not the issue
zzz
the problem is apache's 'do I send 304' logic when mod_deflate is enabled
dr|z3d
if apache's adding a gzip suffix to the etag because of the vary header, then it's the issue indirectly. but I'm no apache expert, I dropped apache for nginx many moons ago.
zzz
it's adding it because of mod_deflate, not the vary header
zzz
15 year old bug so I guess we shouldn't hold breath bz.apache.org/bugzilla/show_bug.cgi?id=45023
zzz
entered ticket #454 for that mess
zzz
next up on the http header front, for your consideration dr|z3d : Proxy-Connection
zzz
working on some low-level building blocks and unit tests for phase 2
dr|z3d
roger that, zzz, thanks.
zzz
same story, different day: lightly tested, no problems so far
zzz
see ticket for why we can rip them out
dr|z3d
are you dogfooding the code as you go? :)
zzz
ja, "lightly tested" == dogfood snack
dr|z3d
ok, good scooby.
zzz
arf
dr|z3d
minor thing, zzz, comments in HTTPClient:
dr|z3d
// Will be set to false for non-GET/HEAD, non-HTTP/1.1,
dr|z3d
// Connection: close, Proxy-Connection: close,
zzz
ok
dr|z3d
also here? ->
dr|z3d
} else if (lowercaseLine.startsWith("keep-alive: ") ||
dr|z3d
lowercaseLine.startsWith("proxy-connection: ")) {
dr|z3d
continue;
zzz
that part is right, that's where we strip it
dr|z3d
ok
zzz
the header writing is down lower in the loop, so when we continue there the header doesn't get passed along
dr|z3d
not seeing any issues so far, zzz, looks good.
dr|z3d
tempted to do something with these debug log events because, well, do we need a stacktrace if the behavior is expected? java.net.SocketException: Socket closed
zzz
great
dr|z3d
my general strategy for stacktraces is error and above.
zzz
do as you wish with the logs, the persistence stuff is several months away from getting merged on canon, I don't plan on doing cleanup before then
dr|z3d
no worries
dr|z3d
we don't actually have persistence yet, though, do we.. it's all preparatory work right now?
zzz
what you have is browser-socket persistence, which is a very modest improvement; the main course is i2p-socket persistence, what I'm calling phase 2
dr|z3d
ok, thanks.
zzz
phase 1 is mostly prep and making me smarter; the modest reduction in resource usage is the bonus, but I'm sure it's not measurable
dr|z3d
onwards and upwards!
dr|z3d
anyone on + dev builds can now try out zzz's browser-socket persistence in the latest -58+ build.
zzz
yup
zzz
phase 2 ofc requires support on both sides so it's harder and is not immediately useful
zzz
I;ll be working on the client side this week