On Sat, Jun 25, 2022 at 09:01:07PM +0200, Magnus Hagander wrote:
> On Sat, Jun 25, 2022 at 8:47 PM David G. Johnston <david.g.johnston@gmail.com> wrote:
>
> > On Sat, Jun 25, 2022 at 11:40 AM Justin Pryzby <pryzby@telsasoft.com> wrote:
> >
> >> I used to be able to wget the "download mbox" link.
> >> https://www.postgresql.org/list/pgsql-hackers/
> >>
> >> I hope that can be fixed, unless it was deliberate, which would be
> >> unfortunate.
> >>
> > It was intentional.
Oh, it's unfortunate then. I'm used to using wget to retrieve a mailbox on a
remote host over SSH. In the immediate case, the "resend email" link is not
working (maybe it did work, but I cannot find the mail and I gave up waiting).
When I finally saved it in my web browser, it took me 5 minutes to realize that
I'd saved it locally and that I'd need to scp the mailbox to the remote side.
I've also retrieved the mailbox to a remote server to retrieve someone's
patchset to compile on the remote side.
> It was indeed deliberate. Are there any locations where it still *tells*
> you to use the archives/antispam method?
Not to my knowledge - just muscle memory.
> FWIW, the old method should still work fine as long as you provide the
> username/password in basic auth up front.
I tried but haven't gotten this to work yet.
curl -u 'archives:antispam' -L -v
http://www.postgresql.org/message-id/flat/126b4480-359c-b745-a713-336ae96d1936%40inbox.ru
> Can you explain exactly the scenario in which it fails? Like, what command
> did you actually use?
I used this command:
wget https://www.postgresql.org/message-id/flat/126b4480-359c-b745-a713-336ae96d1936%40inbox.ru
and the web server happily responded with a 200 OK, so wget didn't retry, as it
used to.
If it had responded with HTTP 403, wget would've retried with basic
authentication (I think it's deliberate and even suggested by RFC to initially
attempt without sending a password, even if one is available).
--
Justin
