views:

447

answers:

1

I'm developing a browser plugin and server component system that streams content with a custom encoding type. Now I would like to be able to detect on the server side whether the client can handle the special encoding, and would like to keep it consistent with the usual way things work with HTTP, so from the browser plugin I would like to add a new encoding in the Accept-Encoding request header. i.e.:

Accept-Encoding: gzip, deflate, myencoding

I have tried implementing IHttpNegotiate and setting it as an additional header in BeginningTransaction, but it seems to either ignore it or it gets overwritten later.

+1  A: 

Please don't try to do this. Any approach that would allow you to modify the Accept-Encoding header (e.g. Asynchronous Pluggable Protocol wrapping) would necessarily be a hack, and will not work reliably because WinINET, proxies, etc, all make assumptions about the Accept-Encoding and Content-Encoding headers, and introducing a new scheme will not be reliable.

For instance, I've heard that one of the popular proxies will treat unknown encodings as GZIP and rewrite the Content-Encoding header in response; obviously that will break your scheme.

EricLaw -MSFT-
Interesting. What's the point of an HTTP spec if so many things are going to break it? Anyway, this is for use in a specific corporate environment, so the proxy issue really would not be a problem; we've already thoroughly tested this scheme in Firefox in this environment. But what assumptions does WinINET make about the Accept-Encoding header?
Gerald
Anyway, thanks for the answer. Taking this into consideration, plus the apparent hackery involved in getting this to work in IE, I've decided to just use a separate request header, and continue with my original plan of using a custom MIME type instead of a Content-Encoding.
Gerald