dr|z3d
after some trial and error, I think I've got fallback headers working in I2PTunnelHTTPServer, zzz: git.skank.i2p/i2pplus/I2P.Plus/src/commit/f744894cfeb903ae6072dc46e9079d94d4602efb/apps/i2ptunnel/java/src/net/i2p/i2ptunnel/I2PTunnelHTTPServer.java
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...
dr|z3d
:)