Re: Test wiki cache problem

It would be probably good to file an infrastructure issue at
project.webplatform.org.


☆*PhistucK*


On Wed, Nov 20, 2013 at 5:27 AM, 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?
>
>