IRCaBot 2.1.0
GPLv3 © acetone, 2021-2022
#saltr
/2023/10/12
~dr|z3d
@RN_
@StormyCloud
@T3s|4
@eyedeekay
@orignal
@postman
@zzz
%Liorar
+FreefallHeavens
+Xeha
+acetone
+bak83
+cancername
+cumlord
+hk
+profetikla
+uop23ip
+weko
An0nm0n
Arch
Danny
DeltaOreo
Irc2PGuest21357
Irc2PGuest21881
Irc2PGuest43426
Leopold
Meow
Nausicaa
Onn4l7h
Onn4|7h
Over1
RN
T3s|4_
anon2
anu3
boonst
mareki2pb
not_bob_afk
plap
poriori_
shiver_
simprelay
solidx66
thetia
tr
u5657
dr|z3d not sure how you feel about that, probably not a huge fan of the idea, but it seems pretty good at picking up the slack where server-side headers are missing.
dr|z3d it should probably be a checkbox option in the tunnel manager, but for now it works as intended.
zzz what's a "fallback header"?
dr|z3d choice headers where the server omits to provide them.
dr|z3d cache-control being the main one.
dr|z3d and it's selective, based on mimetype, so html/xml etc get a no-cache policy, css, images, media etc get an immutable policy.
zzz seems like a fool's errand for a proxy to try to do favors for the server or browser, both projects which have about 1000x the dev resources we do
dr|z3d I politely disagree.
dr|z3d If speeding up the network is a general goal, that's a good, cheap way of doing it.
zzz ok, so the goal is caching, not generalized fix-up-headers
dr|z3d sure, the main objective is to reduce the number of requests and data transfer server-side, where it's not needed.
dr|z3d we can throw in some referrer-policy, allow and X-XSS headers for good measure, but it's not intended to fix every omission.
zzz RFC 2616 has 25 pages to say about caching... I wouldn't go near trying to do caching and/or inject caching headers in the proxies
zzz way too hard
dr|z3d well, it's done and it works. :)
dr|z3d compared to what you're attempting with persistent connections, I'd venture to say it's trivial :)
dr|z3d teddit.i2p is using the code, if you want to see it in action.
dr|z3d not sure teddit's the best exemplar, given reddit's rate limiting these days.. it's a bit unpredictable, but hey.
dr|z3d skank.i2p and git.skank also on it.
zzz to the extent e.g. Jetty is lacking, we should fix up the default eepsite config
dr|z3d yeah, that's another thing I've looked into, but this goes beyond jetty.
dr|z3d I wanted to do cache-control based on mimetype in jetty, couldn't get it to work.
dr|z3d we also win at the outproxy side of things, if clearnet/onion sites don't have an explicit caching policy.
dr|z3d or do we? maybe not, let's see..
dr|z3d yeah, I think we probably do.
zzz so you're right. Not a huge fan :) It's not terrible, but if it breaks some site you'll never find out about it, that's my issue
dr|z3d I was having occasional null reference issues, presumably because the mimetype wasn't being returned in the response for some files, but setting the mimetype explictly seems to have addressed that issue where I was seeing it.
dr|z3d and sure, hypothetically it _could_ break something along the way, which is why a UI checkbox in the tunnel config would be a good idea, at least then you can turn it off. tending towards opt-out rather than opt-in on the basis that those that know about headers probably already have then configured.
zzz you seem to have switched to a java-8 coding style and it's a lot harder for me to spot problems with that code
zzz e.g. boolean immutableCache = Arrays.stream(immutableCacheWhitelist).anyMatch(mimeType::matches);
dr|z3d sexy, huh? ;)
zzz gibberish to me
zzz all the functional programming stuff makes my head hurt
dr|z3d check array for mimetype, assign boolean value to immutableCache. syntax is a bit different, but it should work fine enough.
zzz I'm sure it does, and I'm sure at some point I'll need to learn the Java 8 stuff like Spliterators, and we'll have to update our style guide on what we can and can't do in our codebase
zzz but not today...