W3C home > Mailing lists > Public > public-webplatform@w3.org > November 2013

Re: Test wiki cache problem

From: Renoir Boulanger <renoir@w3.org>
Date: Wed, 20 Nov 2013 11:57:13 -0500
Cc: Max Polk <maxpolk@gmail.com>, Webplatform List <public-webplatform@w3.org>
Message-Id: <1244F7D3-3800-4CF6-943D-4583C3D93AA6@w3.org>
To: PhistucK <phistuck@gmail.com>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:13:55 UTC