Strange AJAX issues: please have a look

[monty]

Hey everybody,

Before I start, let me thank you in advance for reading this post and looking into my problem. Apologies for the length of this post

Right, here it goes! My and my team manage and maintain booking system for a travel company in Thailand. The system runs of a server in Europe using several MySQL databases and a HTML/JS web based interface. This interface allows our partners from Europe and the US to enter bookings into the database.

About a month and a half, our partner in the UK starting mentioning problems when using the web site. Our server logs showed that they were still able to perform the same operations as before, only now there was a fail rate of about 25% (for example searching for data would go well the first three times but result in a error the fourth time). Furthermore, our logs showed no problems on the server side. What we usually do when a partner is having problems using our site, is we recreate the environment in which they where using the site (using the same OS and browser usually) and try to recreate the error and fix it. Usually we are able to fix problems this way, however for this case we were not able to get at the same problem as our partner.

This made us look at the client side. The web site is heavy on Javascript and uses AJAX for about 90% of the server requests. We never implemented client side JS logging, so this seemed like the right time to do so. We implemented a logging system and allowed the users of our site to send the log to the web admin by email when experiencing any issues.

These logs showed us the following: there are issues both with IE (6 and 7) and with FF. The problem that seems to occur most is a GET request is made and response is send by the server (all well, response code is 200) however the responseText attribute of the request object is empty. Now, most of us would say it looks like a server issue. However in 75% of exactly the same requests, the right data is send back by the server. And this problem only occurs at ONE partner, we haven't and other partners mentioning the same thing.

Now, we are going kinda crazy not being able to fix this problem and not being able to recreate on our own systems.

Anybody any ideas about what could go wrong here? If you need more info, please let me know. Thanks for the help!

 

[TwistMyArm]

Any chance of a proxy being involved? Whenever I hear "weird problems" and "one client" I think back to the time when the company I worked for was using a MS proxy of some sort... all sorts of craziness there.

 

[monty]

Thanks for your response TwistMyArm.

That possibility passed my mind also. However, I have spoken to our partners web/it guy who says there is no proxy involved. Furthermore, the problem is quite recent (started about one and a half month back), if somebody placed a proxy there recently, someone should know about it.

Anyway, thanks again.

Mattijs

 

[TwistMyArm]

Strange. Well good luck, but with things like this, sometimes it's easiest to either go to the place yourself or at least get a remote desktop connection to one of the failing computers to start seeing it exactly.... Good luck!

 

[aween]

Did you do any recent changes in the past. Perhaps you have updated a certain section of the system?

 

[DylanButler]

You mention cross-country malfunctions. I wonder if there could be an encoding problem with a particular machine at your associates place? Without more constants about the process towards replicating the issue, it's quite difficult to troubleshoot.

ResponseText will return empty if there's encoding conflicts. I have to ask, you are using UTF-8?

EDIT: If the server is correctly receiving requests, then my post is useless

 

[cef]

Are you sending the data in XML format? If so, try taking a look at the responseXML property and seeing if that's empty as well. Just a thought.

 

[monty]

Hey guys,

Thanks much for responding!

@TwistMyArm
I completely agree, I am scheduled to fly to London in about two weeks. However, I would like to be as prepared as possible since I have limited time (one and a half day) to get the matter resolved.

@xlusive
We are working on the system constantly without using a version control system. But after updating stuff, we usually do extensive testing on our side before implementing the changes. I was worried that the problems were being caused by updates on the system, however if this would be the case then other partners should report similar problems.

@DylanButler
The problem is the same for all office employees at our partners site. I am not quite sure which encoding you are referring to, encoding of the data being send from server to client (or client to server) or encoding of the web interface? Anyway, the server always sends back a valid response, so I guess that would mean the requests are being received properly. Thanks anyway!

@cef
We are using JSON in plain text.

Anymore suggestions, or any ideas what I should prepare before for visiting our partner? Thank again!

-mattijs

 

[monty]

Hey everybody,

I have somewhat of an update on the matter; I just received a JS log from our partner in the UK which mentions a 302 response error.

W3C says the following:

The requested resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the client SHOULD continue to use the Request-URI for future requests. This response is only cacheable if indicated by a Cache-Control or Expires header field.

The temporary URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s).

If the 302 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.

Note: RFC 1945 and RFC 2068 specify that the client is not allowed
to change the method on the redirected request. However, most
existing user agent implementations treat 302 as if it were a 303
response, performing a GET on the Location field-value regardless
of the original request method. The status codes 303 and 307 have
been added for servers that wish to make unambiguously clear which
kind of reaction is expected of the client.

Anybody any ideas what this might mean?

 

[aween]

Ok, i will name a few things that could be the issue:

1. Do you use any headers to redirect the user ( since 302 is a temperory redirect )
You can either send a request with JSON to send it with and without a header. RFC does allow a page to be rendered without a header, although it could be a possible issue, where you want to look at.

In this example: Header("Location: .... ");

2. A other issue would be: Does the server supports foreign languages. I have seen with websites, using JSON/ AJax in general and normal websites written in PHP/ASP and other programming languages that if the server/user doesnt support a certain language it shows [] [] [] [] blocks, and there for the 302 response could be "blocked" to send a request and pops up a error.

3. Any other server upgrades done? Are they all running the same versions of the software installed ( not the scritps, but PHP/MYSQL/ any other backend programme)