[Bug]: test/pdfs/bug1443140.pdf.link link to webarchive is broken

[Rob--W]

Attach (recommended) or Link to PDF file

https://github.com/mozilla/pdf.js/blob/8af3060887b0652d01b828cdffbb612b16246588/test/pdfs/bug1443140.pdf.link

Steps to reproduce the problem

Take a look at the PDF linked from test/pdfs/bug1443140.pdf.link:

pdf.js/test/pdfs/bug1443140.pdf.link

Line 1 in 8af3060

https://web.archive.org/web/20180324105403/https://engineering.purdue.edu/~chengkok/papers/2005/p507-li.pdf

It is a webarchive link, which (used to resolve) to a PDF.
Although the entry is still listed at https://web.archive.org/web/20180415000000*/https://engineering.purdue.edu/~chengkok/papers/2005/p507-li.pdf, it no longer points to the PDF. Instead, the following redirect chain happens:

• https://web.archive.org/web/20180324105403/https://engineering.purdue.edu/~chengkok/papers/2005/p507-li.pdf
• https://web.archive.org/web/20240803181025/https://engineering.purdue.edu/~chengkok/papers/2005/p507-li.pdf
• https://web.archive.org/web/20240803181025/http://www.ecn.purdue.edu/PAPERS
• https://web.archive.org/web/20240723112425/http://www.ecn.purdue.edu/PAPERS
• https://web.archive.org/web/20240723112425/https://engineering.purdue.edu/PAPERS
• https://web.archive.org/web/20240723112425/http://www.ecn.purdue.edu/PAPERS
• (repeat last redirect loop)

What is the expected behavior?

The externally linked PDFs should resolve. This may be a bug in the webarchive.

If the webarchive cannot be relied upon for archiving test PDF files, we'd have to host the PDFs elsewhere.

What went wrong?

The link points to an infinite redirect loop on the webarchive.

[Rob--W]

Next step is to reach out to the webarchive to ask whether the item was taken down erroneously: https://help.archive.org/help/i-cant-find-my-items/

Considering that the entry is still listed in the timeline, I think that this may be an error.

[calixteman]

Yes, we talked with @marco-c about having a private repo containing the files we need.
The main drawback of having a private repo is that it won't help external people to see them...
Anyway, we should fix that next year.

[Rob--W]

Why does the repo need to be private? The PDFs linked here are public, and should continue to be public. Making it a private repo makes it harder to contribute to this project.

[marco-c]

@Rob--W the PDFs might be protected by licenses which don't allow us to redistribute them.

[Rob--W]

Quoting @timvandermeij from PR #20527 which disables the test on Talos as a work-around:

Yes, for now merging this is fine but that the file disappears is a bigger issue (and in general why we do our best to avoid linked test cases and prefer in-repo test cases where possible).

Moreover, while this works for Talos it'll still break if someone does a clean clone of PDF.js and then attempts to download the PDFs.

I managed to find the original paper at https://dl.acm.org/doi/pdf/10.1145/1120725.1120923, but it's not the same PDF because it has an extra page, so the question is: does that file still cover the original bug, or was it re-generated to no longer have the issue?

The original PDF was introduced as a regression test for https://bugzilla.mozilla.org/show_bug.cgi?id=1443140
I opened Firefox 58 (which was the version used by the original reporter) and confirmed that page 5 of the new PDF that you shared still looks like the bugzilla report. Your alternative PDF file is therefore still a good regression test for the original bug.

[Rob--W]

So I see two paths forward for this specific bug:

• Contact web archive and ask them whether they have a bug. If their take down is intentional, then:
• Update our PDF link to the one from https://dl.acm.org/doi/pdf/10.1145/1120725.1120923 (found by @timvandermeij )

I'd like us to check in with the web archive first, because a bug in the integrity of the web archive can impact many others, beyond just our project here.

[rvandermeulen]

I saved a copy of the original PDF from an older talos-pdfs toolchain archive too in case there was somewhere else we could upload it to (the licensing is what concerns me too given it being an academic paper).

[Rob--W]

I have reached out to info@archive.org with subject Item missing: PDF link at purdue.edu and the following message:

This link used to point to a PDF file, but now results in an infinite redirect:
https://web.archive.org/web/20180324105403/https://engineering.purdue.edu/~chengkok/papers/2005/p507-li.pdf

Is this intentional or a bug?
For more details, see #20528

We have alternative options, but I'm reaching out to make sure that this is not a defect on your end that affects others.

[Rob--W]

I got a reply to my email:

Strange! The URL in question is loading the PDF perfectly fine on my end, but please let us know if this is still looping/redirecting. There are two archives of that URL, and while the later snapshot does seem to be redirecting the way you describe, the 2018 one you've attached is fine.

I can confirm that the linked PDF loads fine now, so #20527 can be reverted.