Re: Test wiki cache problem

Hi all,

I'm about to have a look at it.

Renoir 
~

On 2013-11-19, at 10:27 PM, Max Polk <maxpolk@gmail.com> wrote:

> 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 16:15:30 UTC