- From: Renoir Boulanger <renoir@w3.org>
- Date: Wed, 20 Nov 2013 11:57:13 -0500
- To: PhistucK <phistuck@gmail.com>
- Cc: Max Polk <maxpolk@gmail.com>, Webplatform List <public-webplatform@w3.org>
- Message-Id: <1244F7D3-3800-4CF6-943D-4583C3D93AA6@w3.org>
Hi Max, PhistucK @Max: Can you provide me some curl command to replicate the behavior? Also, For the record, I created an issue [0] And I'd like you to give a try on the http://test.webplatform.org/ subdomain, it is where I am testing new configurations on a separate (non live) backend server. I'll keep progress on the issue [0] and keep you posted here about the progress. [0]: http://project.webplatform.org/infrastructure/issues/INFR-60 Renoir ~ On 2013-11-20, at 2:03 AM, PhistucK <phistuck@gmail.com> wrote: > 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? > >
Received on Wednesday, 20 November 2013 16:57:18 UTC