Page MenuHomePhabricator

Empty respond for fawikinews recentchanges (works when using debug=true)
Closed, ResolvedPublic

Description

Hello,

I'm getting empty respond from Wikimedia servers when I request to load recent changes at fawikinews,
please check,

Thanks.

Event Timeline

Mjbmr raised the priority of this task from to High.
Mjbmr updated the task description. (Show Details)
Mjbmr changed Security from none to Software security bug.
Mjbmr subscribed.
Restricted Application changed the visibility from "Public (No Login Required)" to "Custom Policy". · View Herald TranscriptDec 17 2014, 11:46 AM
Restricted Application changed the edit policy from "All Users" to "Custom Policy". · View Herald Transcript
Restricted Application added a project: acl*security. · View Herald Transcript
Aklapper renamed this task from Empty respond at fawikinews recetchanges to Empty respond for fawikinews recentchanges (works when using debug=true).Dec 17 2014, 12:38 PM
Aklapper edited projects, added WMF-General-or-Unknown; removed acl*security.
Aklapper changed the visibility from "Custom Policy" to "Public (No Login Required)".
Aklapper changed the edit policy from "Custom Policy" to "All Users".
Aklapper changed Security from Software security bug to None.

I've unset the access restrictions for this task in Phabricator as I don't see any security issue here.

When did this problem start?

I assume this is about https://fa.wikinews.org/wiki/ویژه:تغییرات_اخیر
(Steps to reproduce are always very welcome. :)

https://fa.wikinews.org/wiki/%D9%88%DB%8C%DA%98%D9%87:%D8%AA%D8%BA%DB%8C%DB%8C%D8%B1%D8%A7%D8%AA_%D8%A7%D8%AE%DB%8C%D8%B1?debug=true works for me.

$:andre\> wget https://fa.wikinews.org/wiki/%D9%88%DB%8C%DA%98%D9%87:%D8%AA%D8%BA%DB%8C%DB%8C%D8%B1%D8%A7%D8%AA_%D8%A7%D8%AE%DB%8C%D8%B1
Connecting to fa.wikinews.org (fa.wikinews.org)|91.198.174.192|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 0 [text/html]

This started some hours ago, and yes any appending query works.

I looked at this a bit yesterday and it seemed that the Varnish servers has cached an empty page for this URL. Appending a query string was bypassing the Varnish cache and fetching the page directly from the backend servers.

I just checked and the page is rendering as expected to both authenticated and unauthenticated users again without URL manipulation.

@Mjbmr are you still seeing this issue on any pages?

The issue was resolved right after my last comment but it was odd. so please make sure it won't happen again 'cause people mostly won't append anything to URL and they blame it on sysops.

Aklapper claimed this task.

Closing as per last comment. Thanks everybody!

@bd808 Can you give me a little bit more information on what happened that day?

@bd808 Can you give me a little bit more information on what happened that day?

I don't remember any specifics beyond what I wrote on 2014-12-18. The page without additional url parameters was returning with http "X-Cache" headers that indicated a varnish cache hit. The next day the content was correct.

Testing today with curl -v https://fa.wikinews.org/wiki/%D9%88%DB%8C%DA%98%D9%87:%D8%AA%D8%BA%DB%8C%DB%8C%D8%B1%D8%A7%D8%AA_%D8%A7%D8%AE%DB%8C%D8%B1 shows headers indicating that varnish is not caching the page:

< HTTP/1.1 200 OK
< Server: nginx/1.1.19
< Date: Sun, 08 Feb 2015 22:02:28 GMT
< Content-Type: text/html; charset=UTF-8
< Transfer-Encoding: chunked
< Connection: keep-alive
< X-Content-Type-Options: nosniff
< X-Powered-By: HHVM/3.3.1
< Content-language: fa
< X-UA-Compatible: IE=Edge
< X-Frame-Options: DENY
< Vary: Accept-Encoding,Cookie
< X-Varnish: 2999771116, 2495361043, 2368179464
< Via: 1.1 varnish, 1.1 varnish, 1.1 varnish
< Age: 0
< X-Cache: cp1066 miss (0), cp4008 miss (0), cp4009 frontend miss (0)
< Cache-Control: private, s-maxage=0, max-age=0, must-revalidate