Re: [PATCH 1/1] snapshot::web Fix internal redirects to farm
On Wed, 2024-11-20 at 12:34 +0100, Philipp Kern wrote:
> Hi,
>
> On 11/20/24 7:58 AM, MOESSBAUER, Felix wrote:
> > > One point I'd make is that we could cache better with the
> > > redirect in
> > > place: The cache can keep the file by-hash for multiple snapshot
> > > timestamps - because it'd be kept by /file/hash key. Assuming
> > > that
> > > people request similar debs from different snapshot timestamps.
> >
> > That's true, but then we need to get rid of the existing varnish
> > redirect as well. Also, apt-cacher-ng 3.7.4-1 (bookworm) does not
> > support these redirects, so we need a proposed-update for that
> > component [1].
>
> apt-cacher-ng sends a distinctive User-Agent:
>
> > 127.0.0.1 - - [20/Nov/2024:01:03:38 +0000] "GET
> > /archive/debian/20180325T111329Z/dists/stretch/contrib/i18n/Transla
> > tion-en HTTP/1.1" 404 2203 25ms "-" "Apt-Cacher-NG/3.6.4"
>
> Should we try to just reply differently to that User-Agent and DTRT
> for
> it? And then set "Vary: User-Agent" in the response?
We could, but where? In Varnish or in the flask app by not sending the
redirect but serving the file directly?
>
> > > If we knew what the filename(s) were (which should be kinda
> > > unique in
> > > the Debian world!?[1]), we could add a Content-Disposition[2] to
> > > send
> > > the filename to the browser.
> >
> > I started on this in
> > https://salsa.debian.org/snapshot-team/snapshot/-/commit/1aaf5d08f5d3ee1ddd1a3ac9b15f6727b5eebad8
> > ,
> > for debugging purposes, but of course that does not help when
> > serving
> > the files via apache directly.
>
> I think that could be done using mod_rewrite rules. I /think/ (but am
> not sure) that mod_rewrite unescapes before processing args. And you
> can
> forward bits using E=. So we... could. It's just messy.
I just did this, and surprisingly it works! The Apache rules are in the
MR as well.
https://salsa.debian.org/snapshot-team/snapshot/-/merge_requests/25
Cheers!
Felix
>
> Kind regards
> Philipp Kern
--
Siemens AG, Technology
Linux Expert Center
Reply to: