mirror of
https://github.com/ArchiveBox/ArchiveBox.git
synced 2026-04-25 17:16:00 +03:00
[GH-ISSUE #487] Bugfix: WGET paths are not working as expected with trailing slashes #1826
Labels
No labels
expected: maybe someday
expected: next release
expected: release after next
expected: unlikely unless contributed
good first ticket
help wanted
pull-request
scope: all users
scope: windows users
size: easy
size: hard
size: medium
size: medium
status: backlog
status: blocked
status: done
status: idea-phase
status: needs followup
status: wip
status: wontfix
touches: API/CLI/Spec
touches: configuration
touches: data/schema/architecture
touches: dependencies/packaging
touches: docs
touches: js
touches: views/replayers/html/css
why: correctness
why: functionality
why: performance
why: security
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/ArchiveBox#1826
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @cdvv7788 on GitHub (Sep 25, 2020).
Original GitHub issue: https://github.com/ArchiveBox/ArchiveBox/issues/487
Describe the bug
Wget replaces src paths with relative paths. When there is a trailing slash, the relative path fails to point to the correct source.
Steps to reproduce
archivebox add https://some_urlarchivebox serverThe css, images, etc. will be broken (404). Removing the trailing slash fixes the issue.
Screenshots or log output
Software versions
@poblabs commented on GitHub (Sep 25, 2020):
I think I found the issue - at least this helped fix it for me.
Remove the trailing slash from this line, so it looks like:
<a href="/{}/{}" ....@cdvv7788 commented on GitHub (Sep 25, 2020):
I applied @poblabs suggestions in here: https://github.com/pirate/ArchiveBox/pull/488
@pirate if you think it is worth pursuing a fix that allows those paths to support both versions (with and without slash) let me know and I will dig deeper. Otherwise, just close this issue.
@pirate commented on GitHub (Sep 25, 2020):
hmm I remember that trailing slash being important for some edge case when opening files from the filesystem before the archiving was finished. It lets you see a directory index rendered by chrome instead of just an error page.
@pirate commented on GitHub (Feb 1, 2021):
This should be fixed in the latest v0.5.4 release. If anyone is still having issues just comment back here with the failing URLs and where they were seen and I'll reopen.