Forum: Rails Spinoffs (closed, excessive spam) Generic Ajax Problem

I am using Prototype, although I'm not convinced this is really to do
with the Javascript, hopefully someone will have seen this sort of
problem before and can suggest a solution.

Basically I am developing a small app for work which pretty much
entirely relies on Ajax (no page reloads etc). This was working fine
until yesterday when some of the requests just started timing out for
the full 300 seconds, not generating any errors (on either firebug or
the servers php error_log), but just not processing the request.

This problem is exclusive to POST requests where I am trying to update
or create something in the database, however it is not a database
error, as it's not getting that far, it is not even running the first
line of the 'AjaxHandler.php' file that should be called. ( I tested
this by adding a sanity check line of code to write a basic message to
the error_log to say that it was processing that line of code, and
there's no message, despite the fact that there is for all of the GET
requests )

I think it might have something to do with caching, as when I clear
the cache in firefox it works once, however I do have headers that I
thought should be preventing the caching (and had been successfully up
until now) i.e.

header('Expires: Mon, 26 Jul 1997 05:00:00 GMT' );
header('Last-Modified: ' . gmdate('D, d M Y H:i:s') . 'GMT');
header('Cache-Control: no-cache, must-revalidate');
header('Pragma: no-cache');
header('Content-Type: text/xml');

I have made changes over the last few days as I am working on this,
but I can't identify any changes that could possibly have caused this
behaviour. I have deliberately left out any specific code so that if
anyone would need to see bits of code for this I can provide it, but
will avoid posting vast quantities of largely irrelevant code.

Thanks,

Simon

To get started, we can test the caching theory pretty easily. When you 
are
building your request, append "?###" where ### is a randomly generated
token... therefore making each request to a unique endpoint.



On Thu, Jul 3, 2008 at 6:35 AM, SImonJ <simonjjones@gmail.com> wrote:

>
> the cache in firefox it works once, however I do have headers that I
> but I can't identify any changes that could possibly have caused this
> behaviour. I have deliberately left out any specific code so that if
> anyone would need to see bits of code for this I can provide it, but
> will avoid posting vast quantities of largely irrelevant code.
>
> Thanks,
>
> Simon
> >
>


--
Ryan Gahl
Manager, Senior Software Engineer
Nth Penguin, LLC
http://www.nthpenguin.com
--
WebWidgetry.com / MashupStudio.com
Future Home of the World's First Complete Web Platform
--
Inquire: 1-920-574-2218
Blog: http://www.someElement.com
LinkedIn Profile: http://www.linkedin.com/in/ryangahl

Shouldn't matter if these are POST's though, browsers aren't allowed to
cache POST requests.

-Fred

On Thu, Jul 3, 2008 at 9:39 AM, Ryan Gahl <ryan.gahl@gmail.com> wrote:

> To get started, we can test the caching theory pretty easily. When you are
> building your request, append "?###" where ### is a randomly generated
> token... therefore making each request to a unique endpoint.
>

--
Science answers questions; philosophy questions answers.

OK, so I tested the idea of putting a random number on the end of the
url but to no avail.

More weirdness to this issue is that it appears to work as expected
under Firefox 3 on my Ubuntu laptop, but not under firefox 2 on my
Solaris terminal at work... Starts to make me think there is a problem
with the JS, however the request appears just as expected in the
firebug console, but it's just not hitting the PHP file.

Anyone have any ideas at all as I'm starting to lose the will to live
on this one :S

Thanks - Simon

The problem

Have you got a web debugging proxy? It might be time to dig one out and 
see
if you can investigate the request and response and see if it's reaching 
the
server at all.
I use Fiddler, but that's windows.

Gareth

OK, quick update, I downloaded a HTTP monitor plugin for firefox and
discovered that although the request was being created, it wasn't
being completely sent - and would get stuck at something 1100/1198 or
something (the numbers changed slightly every time).

Anyway, I saw that this was working when logged on at a different
terminal, so I decided to try running the page with no firebug and no
http monitor plugin and it worked first time (and fortunately every
time after that).

Has anyone seen this sort of thing before? It's a bit of a pain to be
honest as there's every chance that some of the intended users of the
site might be using these sort of plugins...

Simon

Even before this last mail, my suggestion would have been trying
without firebug. I have hit a different problem (http://
code.google.com/p/fbug/issues/detail?id=650) which I'm sure is firebug
(it is generating an extra HTTP request, rather than failing to submit
one). All I've been able to think of doing is put a note on the page
that it might not work correctly with firefox/firebug: since this is
an internal website, not many users are likely to have fb.