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 https://enwp.org/test, causes a redirect to http://en.wikipedia.org/wiki/test. 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:

<VirtualHost *:443> 
  ServerName enwp.org

  Redirect permanent / https://en.wikipedia.org/wiki/
</VirtualHost>

OPTIONAL: http -> https redirect
<VirtualHost *:80> 
  ServerName enwp.org
  Redirect permanent / https://en.wikipedia.org/wiki/
</VirtualHost>

Adapted from https://linuxize.com/post/redirect-http-to-https-in-apache/#redirect-http-to-https-using-virtual-host

Observations

Chromium browser, network redirect log: from enwp.org domain to wikipedia domain, https-to-http redirect

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)