WebReflection / WebReflection/linkedom
Double encoding of anchor tag href
Nobody has claimed this yet.
- Dominant language
- HTML
- Stars
- 2.1k
- Forks
- 104
- PR merge metrics
- No merged PRs in 30d
Description
Hey,
I've been using your amazing library to extract links from DOM content in a service worker and noticed that achor tags which, for example, lead to some file which has already encoded space characters in the URL (www.test.com/path%20to%20some%20file.pdf) end up with a broken href because the % character is encoded again (www.test.com/path%2520to%2520some%2520file.pdf).
I have a workaround by just calling decodeURIComponent on the href attribute before processing it but I guess that is not the intended behavior and shouldn't be like that.
I am sure that it's related to https://github.com/WebReflection/linkedom/issues/49 and the fix for it here https://github.com/WebReflection/linkedom/blob/5b31c583c79423d97fa1982d9a30a8f0a0982485/cjs/html/anchor-element.js#L18
I would guess and hope it's not a complicated fix.
Thanks a lot for your work!
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with cjs/html/anchor-element.js at the linked implementation and compare it with the related linkedom issue and fix. Reproduce the example using an href containing %20, then verify that reading the anchor preserves the existing encoding instead of producing %2520.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript
- Domain
- web-dev
- Issue type
- Bug
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Activity status
- Stale
- Clarity
- Clearly specified
- Newbie friendliness
- 52/100