Page MenuHomePhabricator

Mobile HTML endpoint returns an empty response
Closed, ResolvedPublicBUG REPORT

Description

Any idea why https://en.wikivoyage.org/api/rest_v1/page/mobile-html/Ramla has no response body? (If it helps in case of CDN issues, I've tried it from both the United States and New Zealand). Thanks.

➜  ~ curl -v https://en.wikivoyage.org/api/rest_v1/page/mobile-html/Ramla
*   Trying 198.35.26.96:443...
* Connected to en.wikivoyage.org (198.35.26.96) port 443 (#0)
* ALPN: offers h2,http/1.1
* (304) (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/cert.pem
*  CApath: none
* (304) (IN), TLS handshake, Server hello (2):
* (304) (IN), TLS handshake, Unknown (8):
* (304) (IN), TLS handshake, Certificate (11):
* (304) (IN), TLS handshake, CERT verify (15):
* (304) (IN), TLS handshake, Finished (20):
* (304) (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / AEAD-CHACHA20-POLY1305-SHA256
* ALPN: server accepted h2
* Server certificate:
*  subject: CN=*.wikipedia.org
*  start date: Aug 22 06:51:12 2023 GMT
*  expire date: Nov 20 06:51:11 2023 GMT
*  subjectAltName: host "en.wikivoyage.org" matched cert's "*.wikivoyage.org"
*  issuer: C=US; O=Let's Encrypt; CN=R3
*  SSL certificate verify ok.
* using HTTP/2
* h2 [:method: GET]
* h2 [:scheme: https]
* h2 [:authority: en.wikivoyage.org]
* h2 [:path: /api/rest_v1/page/mobile-html/Ramla]
* h2 [user-agent: curl/8.1.2]
* h2 [accept: */*]
* Using Stream ID: 1 (easy handle 0x13600a800)
> GET /api/rest_v1/page/mobile-html/Ramla HTTP/2
> Host: en.wikivoyage.org
> User-Agent: curl/8.1.2
> Accept: */*
>
< HTTP/2 200
< etag: "4348906/057a9180-3e18-11ee-b7c7-e2c0ac077bfa"
< content-language: en
< content-type: text/html; charset=utf-8; profile="https://www.mediawiki.org/wiki/Specs/Mobile-HTML/1.2.2"
< vary: Accept-Encoding
< cache-control: s-maxage=1209600, max-age=0
< access-control-allow-origin: *
< access-control-allow-methods: GET,HEAD
< access-control-allow-headers: accept, content-type, content-length, cache-control, accept-language, api-user-agent, if-match, if-modified-since, if-none-match, dnt, accept-encoding
< access-control-expose-headers: etag
< x-content-type-options: nosniff
< x-frame-options: SAMEORIGIN
< referrer-policy: origin-when-cross-origin
< x-xss-protection: 1; mode=block
< content-security-policy: default-src 'none'; connect-src app://*.wikipedia.org https://*.wikipedia.org; media-src app://upload.wikimedia.org https://upload.wikimedia.org 'self'; img-src app://*.wikimedia.org https://*.wikimedia.org app://wikimedia.org https://wikimedia.org 'self' data:; object-src 'none'; script-src app://meta.wikimedia.org https://meta.wikimedia.org 'unsafe-inline'; style-src app://meta.wikimedia.org https://meta.wikimedia.org app://*.wikipedia.org https://*.wikipedia.org 'self' 'unsafe-inline'; frame-ancestors 'self'
< x-content-security-policy: default-src 'none'; connect-src app://*.wikipedia.org https://*.wikipedia.org; media-src app://upload.wikimedia.org https://upload.wikimedia.org 'self'; img-src app://*.wikimedia.org https://*.wikimedia.org app://wikimedia.org https://wikimedia.org 'self' data:; object-src 'none'; script-src app://meta.wikimedia.org https://meta.wikimedia.org 'unsafe-inline'; style-src app://meta.wikimedia.org https://meta.wikimedia.org app://*.wikipedia.org https://*.wikipedia.org 'self' 'unsafe-inline'; frame-ancestors 'self'
< x-webkit-csp: default-src 'none'; connect-src app://*.wikipedia.org https://*.wikipedia.org; media-src app://upload.wikimedia.org https://upload.wikimedia.org 'self'; img-src app://*.wikimedia.org https://*.wikimedia.org app://wikimedia.org https://wikimedia.org 'self' data:; object-src 'none'; script-src app://meta.wikimedia.org https://meta.wikimedia.org 'unsafe-inline'; style-src app://meta.wikimedia.org https://meta.wikimedia.org app://*.wikipedia.org https://*.wikipedia.org 'self' 'unsafe-inline'; frame-ancestors 'self'
< content-location: https://en.wikivoyage.org/api/rest_v1/page/mobile-html/Ramla
< server: restbase2027
< content-length: 0
< date: Thu, 07 Sep 2023 06:05:29 GMT
< age: 3457
< 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=07-Sep-2023;Path=/;HttpOnly;secure;Expires=Mon, 09 Oct 2023 00:00:00 GMT
< set-cookie: WMF-Last-Access-Global=07-Sep-2023;Path=/;Domain=.wikivoyage.org;HttpOnly;secure;Expires=Mon, 09 Oct 2023 00:00:00 GMT
< x-client-ip: 103.131.54.20
< set-cookie: GeoIP=NZ:AUK:Auckland:-36.85:174.77:v4; Path=/; secure; Domain=.wikivoyage.org
< set-cookie: NetworkProbeLimit=0.001;Path=/;Secure;Max-Age=3600
< accept-ranges: bytes
<
* Connection #0 to host en.wikivoyage.org left intact

Event Timeline

akosiaris added a subscriber: akosiaris.

I can reproduce internally, this has nothing to do with the CDN, it looks more like a RESTBase or a PCS service issue.

akosiaris@bast3007:~$ curl -vk http://restbase.discovery.wmnet:7233/en.wikivoyage.org/v1/page/mobile-html/Ramla |grep content-length
< content-length: 0

switching from serviceops to serviceops-radar for the above reason.

Hmm ok thanks. I don't really notice anything out-of-the-ordinary in the article wikitext. Were I behind the CDN I could pare the article down and see if something is tripping the parser but, alas, I'm in front of it.

Actually @akosiaris I'm an idiot. I can cache bust right (re the CDN)? Is that just an edit? Would that bust the same cache as the one I hit through the rest-api? I.e would we double bust

Editing the article will indeed issue cache purge events for both the CDN and RESTBase.

Well for the sake of science... [insert me angrily yelling and saying this should be the top priority of the Wikimedia team]... let's see if they approve it on the Wikivoyage end

@MSantos I'm just curious. How do you get fix like this so quickly in to prod? Do you not have annoying QA engineers? I mean, this was so swift... how does it happen?