1. #1
    Ext User
    Join Date
    Jan 2009
    Posts
    543
    Vote Rating
    0
    dbassett74 is on a distinguished road

      0  

    Default Will Ajax request handle gzipped response?

    Will Ajax request handle gzipped response?


    If I call a URL with Ext.Ajax request that happens to respond with gzipped data, will Ext.Ajax request be able to handle this (unzip it) and use it as normal? Or is there some special thing I have to do? Or does the browser automatically handle it?

  2. #2
    Ext User
    Join Date
    Aug 2009
    Posts
    127
    Vote Rating
    0
    rblon is on a distinguished road

      0  

    Default


    I don't see any reason why the browser wouldn't handle this, just like any other http response.
    But to be honest, I have tried it (and I guess you haven't either)

  3. #3
    Ext User
    Join Date
    Aug 2009
    Posts
    127
    Vote Rating
    0
    rblon is on a distinguished road

      0  

    Default


    An other point about this topic: I think compressing becomes efficient when the response has a reasonable size. Otherwise the overhead of compressing doesn't weigh against the benefit of a smaller response size (if any).
    IMHO, as AJAX responses are usually small, it would be an argument to configure your web server such that AJAX responses are actually not compressed.

  4. #4
    Ext User
    Join Date
    Jan 2009
    Posts
    543
    Vote Rating
    0
    dbassett74 is on a distinguished road

      0  

    Default


    Quote Originally Posted by rblon View Post
    An other point about this topic: I think compressing becomes efficient when the response has a reasonable size. Otherwise the overhead of compressing doesn't weigh against the benefit of a smaller response size (if any).
    IMHO, as AJAX responses are usually small, it would be an argument to configure your web server such that AJAX responses are actually not compressed.
    Sure, totally agree. What I'm talking about specifically is a response containing json data that may be small or relatively large. I thought implementing something where if the json data exceeds a certain threshold, it will compress. But I wanted to be sure Ext.AJAX can handle it.

  5. #5
    Sencha - Community Support Team hendricd's Avatar
    Join Date
    Aug 2007
    Location
    Long Island, NY USA
    Posts
    5,962
    Vote Rating
    10
    hendricd will become famous soon enough hendricd will become famous soon enough

      0  

    Thumbs up


    @DBasset74 -- the underlying XMLHttpRequest object does indeed handle the decompression/SSL for us.

    To verify, make an Ajax request for a javascript source file.
    Then, examine the headers returned in the XHR request using Firebug's Net tab.
    "be dom-ready..."
    Doug Hendricks

    Maintaining ux: ManagedIFrame, MIF2 (FAQ, Wiki), ux.Media/Flash, AudioEvents, ux.Chart[Fusion,OFC,amChart], ext-basex.js/$JIT, Documentation Site.


    Got Sencha licensing questions? Find out more here.


  6. #6
    Ext User
    Join Date
    Jan 2009
    Posts
    543
    Vote Rating
    0
    dbassett74 is on a distinguished road

      0  

    Default


    Quote Originally Posted by hendricd View Post
    @DBasset74 -- the underlying XMLHttpRequest object does indeed handle the decompression/SSL for us.

    To verify, make an Ajax request for a javascript source file.
    Then, examine the headers returned in the XHR request using Firebug's Net tab.
    Sweet!

  7. #7
    Ext User
    Join Date
    Aug 2009
    Posts
    588
    Vote Rating
    1
    Mike Robinson is on a distinguished road

      0  

    Default


    When your response data-set is "large," to me that's all the more reason to devise a way to keep all that data on the server and to parcel-out only what the client actually requires.

    For instance, let's say that you have designed the ability to do arbitrary searches against huge host data-sets and to browse through the search results. One potential way to do that would be to define a host API that does a search, then hands-back some kind of token or moniker. You install that moniker as a baseParam to a Store object, then reload the store. Your host, meanwhile, knows how to use the moniker (which it issued) to reference the previous search (which it did) and to hand back any requested slice of that search-result. Presto! With a little bit of host-side programming, you have the ability to handle the large data-sets without transferring "all that data," and you're leveraging existing ExtJS classes and protocols to do it.

    That sort of thing . . .

  8. #8
    Ext User
    Join Date
    Jan 2009
    Posts
    543
    Vote Rating
    0
    dbassett74 is on a distinguished road

      0  

    Default


    Quote Originally Posted by Mike Robinson View Post
    When your response data-set is "large," to me that's all the more reason to devise a way to keep all that data on the server and to parcel-out only what the client actually requires.

    For instance, let's say that you have designed the ability to do arbitrary searches against huge host data-sets and to browse through the search results. One potential way to do that would be to define a host API that does a search, then hands-back some kind of token or moniker. You install that moniker as a baseParam to a Store object, then reload the store. Your host, meanwhile, knows how to use the moniker (which it issued) to reference the previous search (which it did) and to hand back any requested slice of that search-result. Presto! With a little bit of host-side programming, you have the ability to handle the large data-sets without transferring "all that data," and you're leveraging existing ExtJS classes and protocols to do it.

    That sort of thing . . .
    Not sure I follow you here. Are you talking about some type of buffering on the client side so that as you scroll (like viewing a grid), it pulls only the data you need? I really don't like that as it is very jumpy and gives a REAL cheap feel. What do you actually mean by "only what the client actually requires"? If the client did some arbitrary search, isn't that what it requires, all that data??