PDA

View Full Version : Will Ajax request handle gzipped response?



dbassett74
27 Nov 2009, 2:17 AM
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?

rblon
27 Nov 2009, 8:09 AM
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)

rblon
27 Nov 2009, 8:15 AM
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.

dbassett74
27 Nov 2009, 8:51 AM
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.

hendricd
27 Nov 2009, 9:17 AM
@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.

dbassett74
27 Nov 2009, 9:23 AM
@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!

Mike Robinson
1 Dec 2009, 8:26 AM
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 . . .

dbassett74
1 Dec 2009, 2:04 PM
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??