When saving a page with new external link in form of e.g.:
[{{fullurl:tools:~danny_b|foo=bar}} My tools]
given link is saved twice in externallinks table.
Version: 1.18.x
Severity: major
Description
Description
Details
Details
- Reference
- bz33010
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | None | T21270 Relative URIs in interwiki links table break interwiki transclusion | |||
| Resolved | None | T20664 Relative URIs in interwiki links table causes failed redirects | |||
| Resolved | None | T22342 Support for protocol-relative URLs | |||
| Declined | None | T35010 External links using {{fullurl:}} are saved twice into externallinks table |
Event Timeline
Comment Actions
I believe its designed this way for protocol-relative urls, so both http:// and https:// exist in the table.
Comment Actions
(In reply to comment #1)
I believe its designed this way for protocol-relative urls, so both http:// and
https:// exist in the table.
That's exactly right.
Comment Actions
(add a note from irc about the four times thing)
[10:05] <p858snake|l> Danny_B|backup: I believe its needed for our protocol relative urls we use now, RoanKattouw will probably know more (if hes around at this hour)
[10:10] <Danny_B|backup> p858snake|l: well, the other thing is, that some are stored even 4 times
[10:11] <p858snake|l> you might want to add that to the bug with some examples
Comment Actions
(In reply to comment #2)
(In reply to comment #1)
I believe its designed this way for protocol-relative urls, so both http:// and
https:// exist in the table.That's exactly right.
However, two _same_ protocol relative links are stored.
So no for instance:
http://toolserver.org/~danny_b?foo=bar
https://toolserver.org/~danny_b?foo=bar
but twice
//toolserver.org/~danny_b?foo=bar
Comment Actions
Ah, el_index is different, OK, I was checking el_to.
However problem described in comment 3 still applies. - Some URLs are stored 4 times (-> twice a pair of http/https).
I haven't find any dependency on any particular action yet though.
Comment Actions
This way of storing is intentional. And in terms of performance or capacity, this isn't known to be an issue and thus closing since we have enough problems with known capacity symptoms to worry about so as to not need to engage in theoretical ones.
If there is still a true redundancy here, and if that can be solved without adding complexity, then a minor code clean up patch is always welcome in Gerrit, but i don't think we need to keep tasks for that.
Ref T34951: Storing of web links with absolute protocol to the own protocol relative server