Home/ Questions/Q 266859
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-11T23:28:43+00:00

I’m attempting to port over an Internet Explorer plugin to Firefox, but I’m not

  • 0

I’m attempting to port over an Internet Explorer plugin to Firefox, but I’m not sure where to look for what I need.

Basically I need to be able to filter all content that is received by the browser with a certain Content-Type header. I tried implementing a stream converter, and this works, but only for the top-level document in the page, frame, or iframe. I had the same problem with IE, and getting around it was really hacky, and since I would ideally like this to be cross platform I would really like to be able to do this in Firefox without resorting to vtable hacks.

The content is served compressed with a proprietary compression format. So I need to receive the data, decompress it, and change the Content-Type back to what the original uncompressed file should have.

If there is a way to just filter all data received, that would probably be acceptable, I could handle parsing the header myself.

Thanks

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I think I may have found what I needed. I came across this link which is used for tracing HTTP calls: http://blues.ath.cx/firekeeper/resources/http_tracer.html

    There seems to be some problems with the JavaScript implementation for some reason, and I’m not a JavaScript guru to figure it out, but I’ve implemented it in C++ and initial results suggest that I should be able to modify it for my needs.

    Basically we’re replacing the nsIHttpProtocolHandler service with our own implementation, which keeps a reference to the initial implementation. When a call is made to the service, we just proxy it over to the saved original implementation. Then we provide our own implementation of nsIHttpChannel and nsIStreamListener which we use as proxies too.

    Again we proxy most of the calls back off to the original handlers. But in OnDataAvailable, instead of passing the data on to the underlying nsIStreamListener, we save it using nsIStorageStream. Then in OnStopRequest, after we’ve gotten all of the data, we can decompress it and then call OnDataAvailable on the original handler, followed by OnStopRequest.

    It has worked on some small simple tests so far, but I’ll have to put it through some more rigorous tests… I’ll also have to figure out if I can do the same thing with HTTPS.

    The biggest problem I see at the moment is that it relies on some unfrozen interfaces such as nsIHttpChannelInternal. Can’t be helped though as far as I can tell, and my version compatibility requirements are pretty small, so I can live with it if I have to.

    In the meantime, if anybody has any other suggestions, I’m all ears 😀

    • 0