Now I'm curious; what was the bug/ what was the fix?

Just b/c it was working in FF, doesn't mean that Chrome is sending the same 
headers/info that your server is expecting.  So although it might be the 
client side (ie: the browser), it comes through as a server issue as your 
action/filter/interceptor/etc is not acting as you would expect it to.  But 
like I said, these were a lot of problems I had encountered in the first 
releases of Chrome; so much that we had decided at the time to not support 
it until Google fixed its issues.  Today's version is much better...

Thanks,

Eric

  "Gareth McCumskey" <[email protected]> 
wrote in message 
news:[email protected]...
  It works on Firefox therefore it is not server side.


  Regardless we fixed the problem.


  On Mon, Jan 24, 2011 at 5:33 PM, Eric B. 
<[email protected]> wrote:

    I remember back in the early days of Chrome I used to have problems with 
JS and Ajax as well.  But the newer versions seemed to have resolve the 
problems that I was encountering.

    Have you checked if the problem is Chrome to executing the JS properly, 
or if it is a server side issue in which the filter is not properly 
executed?  Are the Chrome AJAX request properly setting the XML HTTP header? 
(in theory, given that it is JQ, it should all be standard, but you never 
know....).

    I assume you have a separate mechanism for session timeouts; are the 
requests from Chrome properly handled?

    Off the top of my head, my first instinct would be to indicate that 
Chrome JS isn't doing it's job properly, but there may also be a case where 
you might be getting double ajax submissions/requests and your session 
monitoring may not properly be handling the double requests (I also had a 
problem with double requests in the early days of Chrome).

    Have you been able to isolate where the exact problem is occurring?

    Tx,

    Eric

      "Gareth McCumskey" 
<[email protected]> wrote in message 
news:[email protected]...
      Hi all,


      I have interesting problem. Something we have all encountered before 
... browser inconsistencies. This is related to handling session timeouts on 
an ajax request. I'll just layout our current setup.


      We have a symfony filter that detects whether the current request is 
an XML HTTP Request and if the current user session has timed out. The code 
for this is:


      if ($user->isAuthenticated() == false && $request->isXmlHttpRequest())
          {
            return $context->getController()->redirect('users/ajaxTimeout'); 
exit;
          }


      As you can see if the IF conditions are met it redirects to another 
action whose code is:


      sfContext::getInstance()->getResponse()->setHttpHeader("Content-Type", 
"application/json");
      return $this->renderText(json_encode(array("error"=>"session", 
"url"=>"users/login")));


      We also have our jQuery .ajaxSetup as follows on the success callback:


      success : function(response, textStatus, xmlobject) {
            try {
              var json_res = jQuery.parseJSON(response);
              if (json_res.error == "session")
              {
                window.location.href = json_res.url;
              }
            }
            catch (e)
            {


            }


      The workflow is that as soon as an ajax request is made, the filter 
catches the request, and detects the request is AJAX and session has timed 
out so redirects the request to the action code above. The action responds 
with a JSON string which the global .ajaxSetup success callback catches and 
sees that there is a session error and redirects the entire page to the 
login screen.


      It works well in Firefox and IE however in Chrome it doesn't. I was 
wondering if anyone here might have some insight into what might be causing 
the problem.

      -- 
      Gareth McCumskey
      http://garethmccumskey.blogspot.com
      twitter: @garethmcc
      identi.ca: @garethmcc



      -- 
      If you want to report a vulnerability issue on symfony, please send it 
to security at symfony-project.com

      You received this message because you are subscribed to the Google
      Groups "symfony users" group.
      To post to this group, send email to 
[email protected]
      To unsubscribe from this group, send email to
      [email protected]
      For more options, visit this group at
      http://groups.google.com/group/symfony-users?hl=en


    -- 
    If you want to report a vulnerability issue on symfony, please send it 
to security at symfony-project.com

    You received this message because you are subscribed to the Google
    Groups "symfony users" group.
    To post to this group, send email to 
[email protected]
    To unsubscribe from this group, send email to
    [email protected]
    For more options, visit this group at
    http://groups.google.com/group/symfony-users?hl=en




  -- 
  Gareth McCumskey
  http://garethmccumskey.blogspot.com
  twitter: @garethmcc
  identi.ca: @garethmcc



  -- 
  If you want to report a vulnerability issue on symfony, please send it to 
security at symfony-project.com

  You received this message because you are subscribed to the Google
  Groups "symfony users" group.
  To post to this group, send email to 
[email protected]
  To unsubscribe from this group, send email to
  [email protected]
  For more options, visit this group at
  http://groups.google.com/group/symfony-users?hl=en

-- 
If you want to report a vulnerability issue on symfony, please send it to 
security at symfony-project.com

You received this message because you are subscribed to the Google
Groups "symfony users" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/symfony-users?hl=en

Reply via email to