Test wiki cache problem

There is definitely a routing and/or caching problem in the test wiki, 
and we need a system administrator to look into it.

I did a login request using a POST to 
http://docs.webplatform.org/t/api.php and the response was from a 
PREVIOUS request!  You can see the response below has an edit.nochange, 
meaning, I just did an EDIT and I had uploaded the same copy as last 
time, so it was a NOCHANGE meaning, don't make a new revision:

{u'edit': {u'nochange': u'', u'contentmodel': u'wikitext', u'pageid': 
4747, u'result': u'Success', u'title': u'Tests/javascript-a/JavaScript 
Reference'}}

The request was for a login action, and the response was for an edit 
action.  That's pretty serious.

I bet this explains the sporadic login problem as well.  On a login, it 
hands you a cookie that must match on your verification of login 2nd 
attempt which I see failing as well at times.

This can be explained if we have multiple downstream servers, and a 
virtual IP address, or round-robin DNS, or a load balancer, configured 
that from one request to the next, requests go to different downstream 
servers that don't share PHP session information.

It can also be explained by a cache in front of the server that needs to 
be completely turned off for any request to api.php, namely these two:
     http://docs.webplatform.org/t/api.php
     http://docs.webplatform.org/w/api.php

The api.php is accessed using a combination of POST and GET.  The POST 
is the most important thing to never cache.  It shouldn't be anyway, so 
it's strange to see this.  So I bet it's some kind of load balancing 
scheme not working right for the sake of the api.php for login and page 
edit.

Who is available to help with this?

Received on Wednesday, 20 November 2013 03:28:27 UTC