Re: Symlink redirection breaks FTP site re-organisation

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Dave Page <dpage(at)pgadmin(dot)org>
Cc: PostgreSQL WWW <pgsql-www(at)postgresql(dot)org>
Subject: Re: Symlink redirection breaks FTP site re-organisation
Date: 2016-06-07 09:38:47
Message-ID: CABUevEw85sqEsCwjcMGVux+h5Zh3Ty7Kc4CjRMSvrr72MWVsHg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-www

On Mon, Jun 6, 2016 at 5:19 PM, Dave Page <dpage(at)pgadmin(dot)org> wrote:

> On Mon, Jun 6, 2016 at 4:02 PM, Magnus Hagander <magnus(at)hagander(dot)net>
> wrote:
> >
> >
> > On Mon, Jun 6, 2016 at 2:11 PM, Dave Page <dpage(at)pgadmin(dot)org> wrote:
> >>
> >> Hi,
> >>
> >> Whilst re-organising the pgAdmin website in preparation for pgAdmin 4,
> >> it became clear to me that the way we currently handle symlinks on the
> >> website FTP browser is broken. For example, the current pgAdmin site
> >> has URLs like:
> >>
> >> https://www.postgresql.org/pgadmin3/release/v1.22.1/...
> >>
> >> I want to change this to:
> >>
> >> https://www.postgresql.org/pgadmin/pgadmin3/v1.22.1/...
> >>
> >> Thus I renamed/symlinked the pgadmin3 dir on Fendaus and the release
> >> dir on Paxsor (the pgAdmin master server), however, whilst when we
> >> encounter a symlink in the browser we re-write it to the target (so
> >> that: https://www.postgresql.org/pgadmin3/ is rewritten to
> >> https://www.postgresql.org/pgadmin/), we don't handle anything deeper
> >> than that, so https://www.postgresql.org/pgadmin/release is a 404,
> >> never mind anything below it.
> >>
> >> So, I'm thinking that we need to have the website stop rewriting the
> >> URLs, or at least generate the index pages under both paths, as you
> >> would see if you traversed the filesystem itself.
> >>
> >> In doing this, I think we should also use a different icon for
> >> symlinks, so users can see that they're following a path (and maybe
> >> display the filename as "pgadmin3 -> pgadmin" as well).
> >>
> >> Thoughts?
> >
> >
> > Every single one of those URLs is a 404... Which makes the discussion a
> bit
> > hard to follow. Is it correct to just inject a "/ftp/" in each case, or
> are
> > there other subtleties to consider?
>
> Err, yeah. Though I had to backout my changes of course as it broken
> links all over the place because of this problem.
>
> Here's a current example though:
>
> https://www.postgresql.org/ftp/pgadmin3/ - This is a "real" directory.
> https://www.postgresql.org/ftp/pgadmin/ - This is a symlink to
> pgadmin3 (i.e. the on-page link is to the URL above)
>
> On a filesystem, the following paths are effectively the same:
>
> /pub/pgadmin3/release/v1.22.1/
> /pub/pgadmin/release/v1.22.1/
>
> However, not on the website:
>
> https://www.postgresql.org/ftp/pgadmin3/release/v1.22.1/ (OK)
> https://www.postgresql.org/ftp/pgadmin/release/v1.22.1/ (404)
>
> This prevents me properly fixing the directory names, and using
> symlinks for backwards-compatibility.
>
>
Ah, gotcha, no I'm following.

I agree that a good way forward is to stop rewriting the URLs. However, I
think the proper thing to do is to detect the case and generate a real http
redirect response for those cases where there's a symlink in the path, and
not generating the indexes in two different places.

E.g. the link would still point to /ftp/pgadmin/, but hitting that would
give you a 301 code sending you to /ftp/pgadmin3/.

There's no reason that can't fairly easily be made to work for deep links
as well - and if we're going to change this around we should get both of
those fixed at once.

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

In response to

Responses

Browse pgsql-www by date

  From Date Subject
Next Message Umair Shahid 2016-06-07 11:47:25 Please grant edit rights for wiki
Previous Message Alvaro Herrera 2016-06-06 23:25:43 Re: Weird glitches for N messages sent to list simultaneously