Vary: Accept-Encoding ?

Question

Hi,

Just wondering whether its possible for MSFT to add to blob/CDN storage "Vary: Accept-Encoding" ?

If a resource is marked "public" in the cache-control - then it should have a "Vary: Accept-Encoding" header added ? Stated here

This should be available via Blob/CDN so that it allows resources to be downloaded from nearby proxy servers as opposed to the remote origin server ?

Thx

Answer 1

Hello, do you mean you want your local proxy server to cache the resource, and some proxies have bugs in detecting Content-Encoding, which can be worked around by setting the Vary: Accept-Encoding header in the response? This doesn't seem to be a problem in CDN. So I'll regard it as a feature request. Please submit a feature request on http://www.mygreatwindowsazureidea.com/pages/34192-windows-azure-feature-voting.

---

Lante, shanaolanxing This posting is provided "AS IS" with no warranties, and confers no rights.

Answer 2

hey yi-lun,

yeah - we want this added to blob/CDN so I guess its a "feature request". that is, whenever a cache-control is marked public it should also contain the header "Vary:accept-encoding" 

this currently doesnt occur and it should ?

thx

Answer 3

Windows Azure Blobs don't support having multiple versions of the blbo with different content encodings, so as I understand it, there's no reason for a Vary: accept-encoding header.  (Caches can simply cache the blob as-is... it will always be the same encoding.)

Answer 4

@ steve

Does that mean that the CDN does not use content compression when delivering files (thinking of Javascript files, for example).

 

Answer 5

Unless there's something I don't know, that's correct.

Answer 6

hey steve,

my understanding of "vary:Accept-encoding" is that regardless of the cache set by the Blob - it instructs local proxy servers to cache the resource and then redistribute it as appropirate. that is, the static resource can be cached on public web proxy servers for redistribution - so if the cache-control is set to "public" then this allows proxy web servers to redistribute the static resource instead of requiring a user to process a remote call request to the origin server.

that is, regardless of whether the blob has multiple versions with different encodings - having "vary:Accept-encoding" in the header allows proxy servers to cache the resource and redistribute it - thereby reducing requests to the origin server. Not having the "Vary:Accept-encoding" header infers that compressed content will be sent to a client that cannot support it regardless - whereas having the header would not send the content thereby reducing transactional rates [by not sending content unless the browser can read it]. the client would have to send the appropriate accept-encoding request header. If an ISP's proxy caches gzipped content and serves it to everyone, then without the header it will be sent to a browser that doesn't support compression. so having the header ensures that content is only distributed to those that can receive it ? so I would think that its still needed regardless of whether both compressed and non-compressed content is supported or not in the blob.

the point of having the header is to ensure that compressed content is only served to those that can read it - not having the header would send the content regardless which is wrong and allows for great inefficiency, increased bandwidth etc etc. ensuring the header is set - ensures that proxy servers will only distribute content to those browsers that can read the encoding (if its compressed) - otherwise they are distributing files everywhere ignoring a browsers capability entirely which pointless if the browser cant read it - in addition to being costly, increasing bandwidth, increasing users cache, increasing transactional processsing etc etc.

@trip the blob allows for the "content-encoding" to be set for "Gzip" [thereby having compression] but this must be set manually and the resource must be GZIP before/on upload to the blob whereby it will then be distributed with GZIP as the content-encoding.

 

Answer 7

[quote]

@sparkcode:

@trip the blob allows for the "content-encoding" to be set for "Gzip" [thereby having compression] but this must be set manually and the resource must be GZIP before/on upload to the blob whereby it will then be distributed with GZIP as the content-encoding.

[/quote]

Which is nice if it weren't for all those fragged up downlevel browsers which don't support gzipped content. Amazon Cloudfront has the same problem. So no javascript on this CDN...

Edit:

I think this should be solvable by a switch that detects gzip in the accept-encoding when accessing the html and render the appropriate javascript file, either compressed or uncompressed. Thoughts?

 

Answer 8

@trip - not sure - as steve said, blobs don't support multiple content-encoding. at the very least - including the vary:accept-encoding will stop the transfer of files that can't be read [saving cost, bandwidth, processing time etc] so I really think its important to add this as default to blobs 

 

Answer 9

I'll flag this for the storage team who will probably understand the header better than I do.

Answer 10

We agree that this response header is useful and have made note of this as a feature request.

 

Thanks,

Jai

Answer 11

Just wondering whether there is any update regarding this ? 

Are we expected to see this soon or ?

Thanks

Answer 12

@SparkCode

 

ROFL - I get more Amazon Updates in a month than Azure updates in a year - go figure...

Answer 13

So I assume by the non-response - it means 

1) No update is coming

2) It's not in the "3-6 month pipeline"

Answer 14

Hi SparkCode, we have no timeline to share at this time.

Thanks,

jai