3

I am working on a project I intended as an academic exercise for myself. What I am basically doing is trying to add a custom compression type between an IIS server and a web browser, but getting mired in the browser aspects of it. What is basically needed is to be able to alter the byte stream on the server before it is sent to the client, and on the client browser side, be able to alter received response byte stream before other normal DOM parsing and such take place. On the server side this turned out to be pretty trivial, but I am at a loss in how to do this in chrome or firefox. If anyone has insight for chrome, please share, but I'll focus on Firefox for now. My understanding is that previously Firefox had rather low level access available to extensions but that they are tightening the restrictions a bit going forward with their Firefox add-on sdk. I don't want to bother learning the old methods if they are slated to be removed so does anyone definitively know if the add-on sdk allows you to alter the byte stream directly in this manner? If so, do you have an example of such usage?

(I am aware that I need to have the compression negotiated with the Accept-Encoding header)

Tim
  • 412
  • 7
  • 18

1 Answers1

2

I don't want to bother learning the old methods if they are slated to be removed

There are no plans now, or in the future, to remove legacy add-on support. At least that's what add-on SDK folks and extension manager folks told me repeatedly.

Back to your question: The add-on sdk does not provide an explicit API for stuff like this, but you can always go even more low-level, even in the SDK (via the chrome module and/or window/utils).

To implement additional compression methods, you'd need to implement the nsIStreamConverter interface and properly register your component under the @mozilla.org/streamconv;1@?from=<yourcompression>&to=uncompressed contract. Then Firefox should be able to decode yourcompression.

  • See https://developer.mozilla.org/ for more information on how to implement and register XPCOM components in either javascript or C++.
  • Using the SDK or implementing your add-on restartless will require you register the component yourself instead of relying on chrome.manifest. There are a couple of add-on doing so already, e.g. Adblock Plus.
  • Binary (C++) components should be avoided because you'll obviously need to compile your component for each supported platform and you'll need to re-compile it for each Gecko version. If you have to go binary, a javascript component stub + js-ctypes might be better.
  • See the mozilla source code on how to implement nsIStreamConverter in the first place.

You may also need to modify the network.http.accept-encoding preference so that the compression may be actually negotiated with the server.

nmaier
  • 32,336
  • 5
  • 63
  • 78