The inconsistent use of trope: and tvtropes: interwiki prefixes is due to trope migration. --Eighty5cacao (talk) 03:24, 8 October 2014 (UTC)
Would it be possible to write a redirection script on your server and retarget the trope: interwiki prefix there, similar to http://pineight.com/redirector.php?site=trope&title=$1? The script should be able to handle [[trope:DarthWiki/UnpublishedWorks]] and [[trope:DarthWiki.UnpublishedWorks]] or (obviously) default to the Main namespace if none is explicitly specified.
Or does your GoDaddy hosting plan not allow such things, in which case we might want to create a template that contains something like <includeonly>[http://tvtropes.org/pmwiki/pmwiki.php/{{{1|Main}}}/{{{2}}} {{{3}}}]</includeonly><noinclude>documentation here</noinclude>? Eighty5cacao 11:24, 17 July 2011 (MST)
<span class="plainlinks"> can be used to hide the external-link icon, which would achieve the desired effect for readers but wouldn't save keystrokes for editors. Should this be mentioned in the context of non-Main TV Tropes linking? Eighty5cacao 12:07, 17 July 2011 (MST)
#REDIRECT wouldn't work. --Tepples 11:57, 31 August 2012 (MST)
#REDIRECT is a feature of the MediaWiki software, and my original proposal involved a script separate from MediaWiki. What part of it do you need me to clarify, if any? I acknowledge that some MediaWiki extensions might turn #REDIRECT into HTTP 3xx, but that doesn't apply to us. (I may as well revert the relevant part of the strikethrough.) Eighty5cacao 23:30, 1 September 2012 (MST)
header("Location: $url");. (stretches for an edge case) The only way it'd theoretically have a problem is if MediaWiki were run in some sort of sandbox with enhanced privileges within the sandbox that customer-written web applications lack. Mostly it's a matter of getting around to writing and testing such a script that converts whitespace to a following capital letter (so that [[trope:we are as mayflies]] becomes the same as [[trope:WeAreAsMayflies]]) and checks whether the page title needs Main/ prepended. --Tepples 07:26, 2 September 2012 (MST)
Pin Eight:Links → Pin Eight:Manual of Style/Links
To match the convention established at Pin Eight:Manual of Style/RFC 2119, as well as Wikipedia's MOS
I could have done the move myself, but I wanted to know if you have objections. Eighty5cacao 13:56, 30 January 2012 (MST)
See title. I first noticed this when looking at 23 Painfully Honest Valentine's Day Cards. Observe that the link to enable article view is not present. I tried manually adding ?view=article to the URL and noticed that it had no effect.
The point is, the MoS should instruct users that they SHOULD link to the specific image page that they want. A quick check of Special:LinkSearch/www.cracked.com shows that the only noncomplying page is my TODO list; I'll fix that ASAP. Eighty5cacao 12:59, 13 February 2012 (MST)
RESOLVED NOTABUG for the specific Photoplasty in question.VERIFIED INVALID for the material redacted from the first paragraph of the OP. Eighty5cacao 14:35, 13 February 2012 (MST)
Yeah, I had some nagging doubts about that but should have acted upon them sooner. This means User:Eighty5cacao/TODO or its talk page would probably have been a better venue, and even there it would probably have been WONTFIX at best. Eighty5cacao 15:15, 13 February 2012 (MST)
Regarding this edit:
Should we change all YouTube links to use HTTPS, or should we change the link you just added to be unencrypted HTTP (for consistency)?
While I understand the importance of "HTTPS everywhere," YouTube video pages almost always have mixed content. At least the video bitstream itself is unencrypted* (the fact that Firefox doesn't complain about this when the Flash player is used is a bug), though other issues crop up occasionally. We want to avoid unnecessarily panicking readers, right?
*...though, I see that YouTube has recently changed their CDN domains from foo.bar.baz.c.youtube.com to foo---bar---baz.c.youtube.com, possibly to facilitate future HTTPS support? Eighty5cacao 13:08, 1 August 2012 (MST)
all_comments pages do seem to have a better chance of being fully encrypted. Eighty5cacao 23:20, 5 August 2012 (MST) (last edit 23:01, 7 August 2012 (MST))
platform field, of which firefox and chrome are among the valid values, but there is no mechanism to detect specific browser versions. The YouTube ruleset has no such field.For what it's worth, some of the aforementioned *.c.youtube.com servers started supporting HTTPS. HTML5 videos on channel (user) pages use this by default (edit: no longer true as of 21:26, 3 October 2013 (UTC)), but my attempt to write an HTTPS Everywhere rule broke videos in all other situations. (It could be an issue with CSP, CORS, and/or the special meaning of some query parameter.) Also, Firefox's current mixed-content blocking system seems to detect the Flash requests fine; the bug in question is being repurposed to deal specifically with POST requests made by plugins. --Eighty5cacao (talk) 04:37, 26 September 2013 (UTC) (+ 01:09, 1 February 2014 (UTC))
*.c.youtube.com domains have moved to *.googlevideo.com. *.googlevideo.com remains in place for a week (a couple days from now, i.e. 01:09, 8 February 2014 (UTC)), we can probably start hard-coding YouTube links to https. --Eighty5cacao (talk) 01:42, 7 February 2014 (UTC)
For the record: Nothing has changed about HTTPS support on pages, but some recent tickets on the Tor Project bug tracker (following the release of HTTPS Everywhere 3.5 and 4.0development.16) suggest that the video streams officially support HTTPS only for the HTML5 player and not Flash. I have not personally used the Flash player in quite a while, so I have not verified what exactly is causing the breakage. --Eighty5cacao (talk) 18:59, 19 April 2014 (UTC)
| Reconsider later |
|---|
|
If you're wondering about the details of this edit summary: Here are the current contents of the ruleset. According to the commit history, the request to disable the ruleset by default was a little over two years old, and the site has been working well enough for a little over a year. By "working well enough" I mean that there is no mixed active content (except possibly for ads/tracking which I have blocked) and that all user-created image content is already protocol-relative (there are sporadic mixed-content problems with emoticons and some other "static" images though, though they are securable and secured by the ruleset). --Eighty5cacao (talk) 22:18, 7 November 2013 (UTC) (+ 07:24, 21 November 2013 (UTC)) |
Do not revert any existing edits without a good reason. For new edits:
HTTPS is fine for hotlinking individual images, but for pages, wait until there is an official statement from the webmaster or the HTTPS-E ruleset is enabled by default.
Although it's still true that everything works, some images on some user pages aren't secured by default for some reason. --Eighty5cacao (talk) 21:51, 22 January 2016 (UTC)
--Eighty5cacao (talk) 22:38, 20 March 2014 (UTC) (+ 00:45, 16 February 2015 (UTC))
I'm thinking of eventually porting trope: from TV Tropes to All the Tropes. TV Tropes switched from a license for free cultural works (Creative Commons BY-SA, the same license as Wikipedia and Uncyclopedia) to a non-free license (Creative Commons BY-NC-SA) in July 2012. This by itself was an infringement of the copyright of all contributors prior to July 2012, including my copyright. But it has come to my attention that to hide this infringement, TV Tropes has been requiring copyright assignments for all contributions over the past six months. All the Tropes is a TV Tropes fork starting from the last free site dump. (Source: Irregular Express, via Slashdot) And it supports HTTPS. But the transition will require editing every page that includes a trope: interwiki link because of different article naming conventions between PmWiki and MediaWiki. --Tepples (talk) 21:07, 29 May 2014 (UTC)
oldtrope, instead of discarding it entirely, once we move allthetropes to trope. --Eighty5cacao (talk) 21:45, 29 May 2014 (UTC)
trope: interwiki to tvtropes:. --Tepples (talk) 01:31, 30 May 2014 (UTC)
trope.php (the target of tvtropes:) be changed to show a user-visible warning (with META REFRESH at your discretion) rather than returning 3xx? --Eighty5cacao (talk) 02:46, 30 May 2014 (UTC)
It appears that the search box on All the Tropes always brings up the full search results instead of going directly to an exact match when one is present. This differs from the Wikipedia and Uncyclopedia behavior. Do registered users have a preference to change this? --Eighty5cacao (talk) 02:46, 30 May 2014 (UTC)
To clarify "do not use shortened URL, as server tries to redirect to http even though the target supports https":
The redirect location the server sends for https://worldbuilding.stackexchange.com/q/542/601
is http://worldbuilding.stackexchange.com/questions/542/how-would-society-be-different-in-a-sentient-species-that-does-not-care-for-its,
but https://worldbuilding.stackexchange.com/questions/542/how-would-society-be-different-in-a-sentient-species-that-does-not-care-for-its loads fine.
There is no intermediate redirect to http://worldbuilding.stackexchange.com/q/542/601 and therefore no redirect loop with HTTPS Everywhere.
My guideline is intended mainly to preserve security for readers without HTTPS Everywhere, for whom protocol-relative or hardcoded-https URLs matter in the first place.
I have not verified whether the behavior is different for logged-in users, which would explain any failure on your part to reproduce this. (As usual, it may help to examine with Live HTTP Headers if you are using Firefox.) --Eighty5cacao (talk) 03:13, 8 October 2014 (UTC)
https://linguistics.stackexchange.com/a/6998/2712) do successfully redirect to an anchor; the anchor is included in the server's 3xx target and is not added by JavaScript after the fact. --Eighty5cacao (talk) 05:34, 13 July 2015 (UTC)
No reply needed except for urgent questions (maybe this should have gone on a user subpage...)
(Existing links)
Ars Technica used to redirect most pages to http for non-logged-in users. This is no longer the case. --Eighty5cacao (talk) 00:09, 31 January 2017 (UTC)
(Existing links)
It appears that they no longer redirect to http. All of our existing linked articles seem fine, except that the oldest one has some mixed images and blocked YouTube embeds. --Eighty5cacao (talk) 05:00, 22 March 2017 (UTC)
(Existing links – )
See above notes for The Verge, not including the part about older articles using a different layout. I haven't checked any other Vox Media properties yet. --Eighty5cacao (talk) 04:27, 30 March 2017 (UTC)
(Existing links)
Related domains known to be broken, with explanation of why they are not major issues:
live.thedailywtf.com - cert mismatch (Amazon S3 alias) - used in some articles for embedded audioplease-support.thedailywtf.com - certificate mismatch - used in some older articles for advertising contentimg.worsethanfailure.com (older articles) and img.thedailywtf.com (more recent) - cert mismatch - content equivalent to thedailywtf.comThere may be mixed-content images in some older articles. --Eighty5cacao (talk) 20:21, 9 July 2017 (UTC) (+ 15:22, 12 July 2017 (UTC), 03:39, 7 May 2019 (UTC))
The previous webmaster request to disable HTTPS Everywhere coverage appears to have been rescinded (ticket #11834, citing this blog post by DeviantArt staff). --Eighty5cacao (talk) 19:10, 13 August 2017 (UTC)
(Existing links)
Everything in *.blogspot.com seems to have working HTTPS, but I stopped my previous cleanup effort when I encountered a blog that had become private. --Eighty5cacao (talk) 06:54, 24 May 2018 (UTC)
(Existing links)
Further evaluation and comments to come soon.
Most links to resources are absolute-https, so no obvious mixed-content problems. --Eighty5cacao (talk) 19:30, 10 July 2018 (UTC)
(Existing links)
No obvious mixed-content problems. --Eighty5cacao (talk) 16:15, 26 December 2018 (UTC)
This site, along with the rest of Konfiskated Teknologies Network, now enforces HTTPS at least via 3xx. However, it contains many outdated absolute references to http://www.hardcoregaming101.net for images, scripts, and stylesheets; these are erroneous because the new Hardcore Gaming 101 doesn't yet support HTTPS and lacks cool-URI redirection for the files in question anyway. --Eighty5cacao (talk) 06:54, 24 May 2018 (UTC)
This discussion is specifically about www.bbc.com; although the same is presumably true for www.bbc.co.uk, I have not tested it extensively because most pages redirect to www.bbc.com for US viewers.
Most articles currently seem to enforce HTTPS at least via 3xx, but implementation mistakes seem to cause redirect loops on the domain's homepage as well as articles in the "future" section. --Eighty5cacao (talk) 22:29, 17 June 2018 (UTC)
--Eighty5cacao (talk) 22:51, 16 March 2019 (UTC)
I am aware of most of the crystal-oscillator values being moved to xtal.cpp while xtal.h still exists for other reasons - still need to look into the details - but it will be a day or two before I can finish dealing with the links here. --Eighty5cacao (talk) 14:46, 23 January 2018 (UTC)