Kunzisoft / Kunzisoft/KeePassDX
IPv6 URL highlighting
- Dominant language
- Kotlin
- Stars
- 7.3k
- Forks
- 401
- Avg merge
- 2d 10h
- Merged PRs (30d)
- 1
Description
### Checks
- [x] I have read the Wiki, searched the open issues, and still think this is a new feature.
### Explain the problem clearly and succinctly:
If an **HTTP** link is contained within the **URL field** of a password entry it is normally **highlighted and clickable**.
This, however, happens **only if** the URL uses `IPv4` or a `domain name`, if it contains an `IPv6 address`, the URL must manually be copied to a browser.
### Describe the solution you'd like:
### IPv6 Textual representation
IPv6 address textual representation is specified in the [**section 2.2 of RFC 4291**](https://www.rfc-editor.org/rfc/rfc4291.html#section-2.2).
In summary, address contains **8 segments** of **16-bit hexadecimal values**. Each segment is separated by `:`
- `ABCD:EF01:2345:6789:ABCD:EF01:2345:6789`
If a segment contains **leading zeros** like: 2001:**0**DB8:**000**0:**000**0:**000**8:**0**800:200C:417A
They **can be omitted** as long as each segment still contains at least one character: `2001:DB8:0:0:8:800:200C:417A`
Furthermore, if two or more segments in a row contains only zeros they can be compressed with `::`
- 2001:DB8:**0:0**:8:0:0:417A -> `2001:DB8::8:0:0:417A`
> Note: It is only possible to use `::` once in an address, so no: `2001:DB8::8::417A`
There is one more way IPv6 address can be written. For convenience when translating between IPv4 and IPv6 the **last 32 bits** of an IPv6 address can be represented the same way **as an IPv4** address: `64:ff9b::198.51.100.253`.
### IPv6 address inside a URL
In a URL, IPv6 address must be enclosed inside square brackets `[ ]`.
For example: `http://[2001:db8:800::200C:417A]:8080/foo`
More details are avaiable in [**section 2 of RFC 2732**
](https://datatracker.ietf.org/doc/html/rfc2732#section-2)
---
### Expected behaviour
Of course, I **do not expect** full, spec compliant syntax validation of an IPv6 address.
It is enough to check for square brackets `[ ]` in a URL.
Additionally, if the protocol is not provided (there is **no** `http://`), but instead the user just typed address with or without brackets, it should open in the default browser while **adding** `http://` at the same time. Please **do not assume** `https`, most websites **will redirect to https** if they support it, but websites which are **http only** won't normally redirect from https back to http.
- `2001:db8:800::200C:417A` -> add **http://** and **brackets**, open in the browser
- `[2001:db8:800::200C:417A]` -> add **http://** and open in the browser
- `[2001:db8:800::200C:417A]:8080` -> add **http://** and open in the browser
- `[2001:db8:800::200C:417A]/hello_world.html` -> add **http://** and open in the browser
> Note: Adding `http://` should be performed before opening the link, the value in the **field** should remain **unchained**, just as the user typed it in.
Also, I do not expect things which are clearly user's fault to work:
- `2001:db8:800::200C:417A:443` - port number mixed with the address
- `2001:db8:800::200C:417A/hello_mom.html` - partial URL without brackets
- `http://2001:db8:800::200C:417A/hello_mom.html` - full URL but still without brackets
- etc.
Neither of these do I expect be clickable. The last two can be argued about, but I think a **user** using **bare addresses** probably **understands** these URLs are **invalid**.
### Describe alternatives you've considered:
_No response_
### Additional context:
_No response_
Contributor guide
Research direction
Locate the URL-field highlighting and browser-opening entry points, then trace how existing IPv4 and domain links are detected and normalized. Add coverage for the requested bracketed IPv6 forms and verify that valid links open with http:// while the field remains unchanged; malformed unbracketed forms should remain unclickable.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- android, kotlin
- Domain
- mobile
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100