google.load - bad headers on CDN components?

[lipiker]

Hi,

I am using google's CDN to serve dojo toolkit for my app, and also to
geo locate my users (through ClinetLocation). I use the google.load
interface to load the libraries.

However, just looking at YSlow, I saw that goole's analytics' dummy
image and jsapi have expires header set in the past, and libraries are
not gzipped (portion of the report report attached below). Is this
intentional? I am based in the UK, but testing through a corporate
gateway in France. My website it htttp://lipik.in

Btw, for Ajaxk loading, I am using jsapi without an API key (I do have
one, but I only use it when using Google's REST functionality).

Thanks
Amit

component, expires, Gzip, load-time, size
-------------------------------------------------------------------------------
http://www.google.com/jsapi, 1/1/1990, , 76,12.7K
http://www.google-analytics.com/ga.js, , ,185, 22.7K
http://ajax.googleapis.com/ajax/libs/dojo/1.2.0/dojo/dojo.xd.js,
11/18/2009, ,101,90.9K
http://www.google-analytics.com/__utm.gif?..., 8/4/1978 , , 126, 0.03K
http://lipik.in/scripts/release/lipik/Client.xd.js, ,gzip, 564, 102.2K
(370.5K)

[Ben Lisbakken]

lipiker --

I am having all of them served with expires headers a year in the future as well as GZipped.  I think I remember this being a problem with proxies, though I'm not 100% positive.  I do know that not all browsers serve GZipped content, so we have to sniff to see if we can serve the browser a GZip.  If your proxy did not correctly identify, then that would be the cause of the problem.

Let me get back to you with a confirmation that this is likely the problem, and any more details.

Regards,

Ben

[lipiker]

OK, Thanks for the reply. I will check from another location later on
tonight. Btw, I can confirm that my browser sets Accept-Encoding:
gzip,deflate in the request.

On Nov 18, 5:31 pm, Ben Lisbakken <lisba...@google.com> wrote:
> lipiker --
> I am having all of them served with expires headers a year in the future as
> well as GZipped.  I think I remember this being a problem with proxies,
> though I'm not 100% positive.  I do know that not all browsers serve GZipped
> content, so we have to sniff to see if we can serve the browser a GZip.  If
> your proxy did not correctly identify, then that would be the cause of the
> problem.
>
> Let me get back to you with a confirmation that this is likely the problem,
> and any more details.
>
> Regards,
> Ben
>

[Ben Lisbakken]

Lipiker --

That sounds like the best approach -- try it from a computer that isn't behind a proxy.

What happens is that your browser's request headers can all be set right, but the request that Google sees is the one sent from the proxy.  So if your proxy sets the headers incorrectly it would look like you are sending the correct ones when you are not.

Thanks,

Ben

[lipiker]

Hi Ben,

I had a look from another network (no proxies involved) - the
components are indeed correctly gzipped, and expire in a year.
However, www.google.com/jsapi has an expiry data of 1990 - is there a
reason for that as well, or is it is misconfiguration? This time I
looked up from a UK network (in case you need to know which node),
though I saw this problem on the French network as well.

Thanks
Amit

On Nov 18, 6:35 pm, Ben Lisbakken <lisba...@google.com> wrote:
> Lipiker --
> That sounds like the best approach -- try it from a computer that isn't
> behind a proxy.
>
> What happens is that your browser's request headers can all be set right,
> but the request that Google sees is the one sent from the proxy. So if your
> proxy sets the headers incorrectly it would look like you are sending the
> correct ones when you are not.
>
> Thanks,
> Ben
>

[Xavier Mathews]

Try Posting This Over At Web Master.

BTW Did You Lock It Field It Code It And Unzip It?

--
Xavier A. Mathews
Student/Developer/Web-Master
Google Group Client Based Tech Support Specialist
Hazel Crest Illinois
xavier...@gmail.com¥xavier...@hotmail.com¥trues...@yahoo.com
"Fear of a name, only increases fear of the thing itself."

[Ben Lisbakken]

Hey Amit --

jsapi actually isn't supposed to be cached.  The reason why is because it is the loader for the rest of the APIs and it is changed frequently.  Because it is not cached, we try to keep it as small as possible.

-Ben