Meta Stack Exchange is where users like you discuss bugs, features, and support issues that affect the software powering all 158 Stack Exchange communities.

What is meta?
Here's how it works:
  1. Any Stack Exchange user can ask a question
  2. The community provides support, votes on ideas, and reports bugs
  3. Your voice helps shape the way Stack Exchange operates

Today, multiple times, I've saved an edit and seen the orange popup saying that the edit save has failed... but actually it's worked, and reloading the page shows the change.

It's not happening on every edit, although possibly every edit on one machine (I've got my home laptop and work laptop going at the same time). I'm happy to provide any more information that would help - it's quite disconcerting...

share|improve this question
may be a cache problem, it happens sometimes – Lucifer May 25 '12 at 11:10
And Jon finally reveals his secrets: answering from two computers simultaneously! – Cody Gray May 25 '12 at 11:37
@Lucifer I don't understand what kind of cache problem you're suggesting would cause this; care to explain? – balpha May 25 '12 at 11:41

According to our logs, the server returned a 302 redirect to some of your edit submissions. This is the correct response if the edit was made from the actual edit page (e.g. like this one), as in this case it's a standard POST/Redirect/GET. But since your edits are inline edits this should not happen; instead, you should receive a 200 response with a JSON object (inline edit submissions are AJAX requests). Trying to parse the response as JSON would thus fail, causing the error message.

To check whether an edit submission is inline or not (they hit the same route), we use .NET's IsAjaxRequest(), which (so the Internet tells me) simply checks for the X-Requested-With HTTP header which jQuery sets when making AJAX requests.

The fact that the server responds with a 302 therefore suggests that this header wasn't received. The obvious theory here is that the machine where these failures occur is sitting behind a proxy that strips this header, or something similar; maybe you could check that?

share|improve this answer
That's entirely feasible - it's on a VPN from home. I'm very happy to check anything - what's the simplest way of doing so? (Any jQuery test-beds you know of which would show the headers received, for example?) – Jon Skeet May 25 '12 at 11:54
@JonSkeet Go to (or a similar site) and put var req = new XMLHttpRequest();"get", "", true); req.setRequestHeader("X-Requested-With", "XMLHttpRequest"); req.onreadystatechange = function () { document.body.parentElement.innerHTML = req.responseText; }; req.send(); into the JavaScript console, that should replace the page content with the data for the Ajax request. It should contain the X-Requested-With header. – balpha May 25 '12 at 12:09
Thanks, just tried it (on the "broken" machine) - it came back with X-Requested-With: XMLHttpRequest – Jon Skeet May 25 '12 at 12:14
What if you replace "get" with "post"? – balpha May 25 '12 at 12:15
Sorry, only just seen this. Trying now... – Jon Skeet May 25 '12 at 13:34
Okay, that's weird... I've just tried it with both get and post, and in neither case did it show the X-Requested-With. I wonder whether I've switched between proxies silently, or something like that. – Jon Skeet May 25 '12 at 13:37

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .