User talk:Tl-lomas/enwp.org

Thank you thank you thank you. Seriously, for mobile devices and people that know the url/name structure this is great. - cohesion 21:01, 31 August 2007 (UTC)

I am using this for a script that converts WP:DYK updates into microblogging-sized messages. See http://identi.ca/enwpdidyouknow. Thanks for providing this service. :) --pfctdayelise (talk) 06:39, 18 August 2008 (UTC)

The enwp.org URL shortening is a sublime idea.
Should be an official service. Absolutely brilliant. —Preceding unsigned comment added by Primary key (talk • contribs) 13:28, 21 January 2010 (UTC)

Feature request: https://enwp.org
Hi, I've been using your shortener for ages to link friends to wp articles while chatting. It is awesome! can you setup a similar shortener at https://enwp.org or http://enwp.org/s/Name_of_the_Page (less awesome) that redirects to https://secure.wikimedia.org/wikipedia/en/wiki/Name_of_the_Page

Thanks a billion —Preceding unsigned comment added by 59.92.204.178 (talk) 05:46, 23 June 2010 (UTC)
 * Goodness knows why I have only just found this - It's one of those little things that makes life so much easier. Please consider a https implementation. -- wintonian  talk  05:24, 2 December 2012 (UTC)

Thanks!
I use this ALL THE TIME. I'm your biggest fan! T3h  1337   b0y  00:35, 2 July 2010 (UTC)

Preventing a switch and bait.
Will you give control of the URL over to the WMF, so we know the forwarding address won't change in the future? -- Jeandré, 2010-09-21t05:05z

Recognition by Google Chrome
It appears Google Chrome now recognises enwp.org to give you the option to search Wikipedia in the omnibar when you type it in. Congratulations! Osarius - Want a chat? 08:08, 27 May 2016 (UTC)

Traffic leak, downgrades https -> http (enwp.org -> wikipedia)
Original concern collapsed away. This text is not collapsible; but the next is collapsible and hidden by default:

Could you please: redirect using the https scheme to Wikipedia, in the location header, for either: all requests; or at least for https requests to enwp.org.

Motivation
The American people expect government websites to be secure and their interactions with those websites to be private.

-- https://https.cio.gov/

Currently, sending a request to, causes a redirect to. I expect that traffic to Wikipedia is private to WMF networks, and the current behavior breaks this assumption, even though enwp exists to provide conveniently succinct URLs for Wikipedia resources. This behavior leaks the non-domain portions of the URL, namely path, or what page is being requested. WMF clearly holds this value, can you uphold it as well?

To preserve the privacy of our users, HTTP requests between PoPs need to be sent encrypted.

--https://techblog.wikimedia.org/2020/10/14/wikimedias-cdn/

Since at least 2010, this outcome has been the goal of downgrade attacks.

Examples

 * Here's some example Apache configuration to support this:

 ServerName enwp.org

Redirect permanent / https://en.wikipedia.org/wiki/   ServerName enwp.org
 * 1) OPTIONAL: http -> https redirect

Redirect permanent / https://en.wikipedia.org/wiki/  Adapted from https://linuxize.com/post/redirect-http-to-https-in-apache/#redirect-http-to-https-using-virtual-host

Observations


In a Chromium browser, here is the network request inspection log.

Redirect logs - curl
$ curl -Lsi https://enwp.org/test   |& less HTTP/2 301 date: Fri, 17 May 2024 19:40:17 GMT server: Apache location: http://en.wikipedia.org/wiki/test content-length: 241 content-type: text/html; charset=iso-8859-1 x-varnish: 2102298558 2035456321 age: 44 via: 1.1 webcache2 (Varnish/trunk)

HTTP/1.1 301 Moved Permanently content-length: 0 location: https://en.wikipedia.org/wiki/test server: HAProxy x-cache: cp4040 int x-cache-status: int-tls connection: close

HTTP/2 301 date: Fri, 17 May 2024 19:34:18 GMT server: mw-web.codfw.main-5fd47cfb8c-xs2mz x-content-type-options: nosniff vary: Accept-Encoding,X-Forwarded-Proto,Cookie,Authorization last-modified: Fri, 17 May 2024 19:34:18 GMT location: https://en.wikipedia.org/wiki/Test content-length: 0 content-type: text/html; charset=UTF-8 age: 404 x-cache: cp4038 miss, cp4038 hit/6 x-cache-status: hit-front server-timing: cache;desc="hit-front", host;desc="cp4038" strict-transport-security: max-age=106384710; includeSubDomains; preload report-to: { "group": "wm_nel", "max_age": 604800, "endpoints": [{ "url": "https://intake-logging.wikimedia.org/v1/events?stream=w3c.reportingapi.network_error&schema_uri=/w3c/reportingapi/network_error/1.0.0" }] } nel: { "report_to": "wm_nel", "max_age": 604800, "failure_fraction": 0.05, "success_fraction": 0.0} set-cookie: WMF-Last-Access=17-May-2024;Path=/;HttpOnly;secure;Expires=Tue, 18 Jun 2024 12:00:00 GMT set-cookie: WMF-Last-Access-Global=17-May-2024;Path=/;Domain=.wikipedia.org;HttpOnly;secure;Expires=Tue, 18 Jun 2024 12:00:00 GMT x-client-ip: 135.180.42.125 cache-control: private, s-maxage=0, max-age=0, must-revalidate set-cookie: GeoIP=US:CA:Berkeley:37.86:-122.28:v4; Path=/; secure; Domain=.wikipedia.org set-cookie: NetworkProbeLimit=0.001;Path=/;Secure;Max-Age=3600

HTTP/2 200 date: Fri, 17 May 2024 10:36:31 GMT server: mw-web.codfw.main-5fd47cfb8c-mxs59 ... Mcint (talk) 20:24, 17 May 2024 (UTC)

It appears that Chrome/Chromium and Firefox address this concern. Chrome sometimes uses 307 redirects as HSTS RFC calls for, but in the case of the http redirect to an HSTS-enrolled domain, seems to use a 301 redirect generated internally in the networking stack, notably responding in 2ms on my machine where real network round trips take 200-300ms. I'm still concerned about this for use with command line tools or less well implemented browsers. --Mcint (talk) 19:08, 24 May 2024 (UTC)