Extension like XmlHttpRequest / nsIDocument / MOZILLA_INTERNAL_API
ksachdeva
I am trying to develope an extension similar to XmlHttpRequest but for
a different protocol than Http. The main functionality of
XmlHttpRequest that I want to emulate is its asynchronous aspect. After
looking inside XmlHttpRequest and its lower layers I know understand
how to do it. I took the path of implementing the protocol handler for
my protocol using an example from
http://www.mozilla.org/projects/netlib/new-handler.html.
Since I want my extension to be compatibile with versions of Firefox
which are 1.5+ I intend to use only frozen interfaces i.e do not want
to use MOZILLA_INTERNAL_API pre-processor. First I made my protocol
handler implementation compile with out using MOZILLA_INTERNAL_API by
using correct string APIs and even copied some utility functions from
nsNetUtil.h (which further includes nsString.h and hence internal
linkage) as its inclusion required the MOZILLA_INTERNAL_API
pre-processor.
But now emulating XmlHttpRequest implementation is giving me similar
problems and I am stuck with no solution for the moment. I am trying to
use nsIDocument.h whose inclusion require MOZIILA_INTERNAL_API and fail
with error message <quote>Cannot use internal string classes without
MOZILLA_INTERNAL_API defined. Use the frozen header nsStringAPI.h
instead</quote>, the same message which I removed earlier from my
handler implementation.
Since Gecko SDK anyway does not provide the headers that I require I am
using the SDK (dist folder) generated by compiling sources of
firefox-1.5.0.4. I have compiled it in debug mode. I am developing my
extension on windows (but would port it on Linux and Mac as well) using
Visual Studio 2003.
I would appreciate if firefox gurus would help me out on this.
Regards & thanks
Kapil
Benjamin Smedberg
> Since I want my extension to be compatibile with versions of Firefox
> which are 1.5+ I intend to use only frozen interfaces i.e do not want
> to use MOZILLA_INTERNAL_API pre-processor. First I made my protocol
Note that "using frozen linkage" and "using only frozen interfaces" are not
the same thing at all. You can use frozen linkage and still use nonfrozen
interfaces.
> But now emulating XmlHttpRequest implementation is giving me similar
> problems and I am stuck with no solution for the moment. I am trying to
> use nsIDocument.h whose inclusion require MOZIILA_INTERNAL_API and fail
> with error message <quote>Cannot use internal string classes without
> MOZILLA_INTERNAL_API defined. Use the frozen header nsStringAPI.h
> instead</quote>, the same message which I removed earlier from my
> handler implementation.
nsIDocument is a very-internal pseudo-interface and it will never be frozen
(it even changed between Firefox 1.5.0.x and Firefox 2). On the Mozilla
trunk we've fixed the headers so that you could use nsIDocument from
frozen-linkage code, but that doesn't help you much on the branches.
--BDS
ksachdeva
> trunk we've fixed the headers so that you could use nsIDocument from
> frozen-linkage code, but that doesn't help you much on the branches.
Does that mean that if I download firefox trunk, generate the SDK and
compile using frozen-linkage code then my extension would be comptabile
with this version of Firefox (trunk) or till the interface nsIDocument
does not change and will not be compatible with Firefox 1.5.* branches
?
Benjamin, I sincerely appreciate your help here and would be very
grateful if you could give me some guidelines in order to achieve my
objective which is to emualte XmlHttpRequest aysnchrnous functionality
in my extension and protocol handler.
Regards
Kapil
Boris Zbarsky
> I am trying to develope an extension similar to XmlHttpRequest but for
> a different protocol than Http.
Note that XMLHttpRequest can make requests to all URIs (file:, ftp:, etc).
Though subject to same-origin checks in some cases.
> I took the path of implementing the protocol handler for
> my protocol using an example from
> http://www.mozilla.org/projects/netlib/new-handler.html.
That sounds like the right way to go... now why do you need nsIDocument, exactly?
-Boris
ksachdeva
Boris Zbarsky wrote:
> ksachdeva wrote:
> > I am trying to develope an extension similar to XmlHttpRequest but for
> > a different protocol than Http.
>
> Note that XMLHttpRequest can make requests to all URIs (file:, ftp:, etc).
> Though subject to same-origin checks in some cases.
>
That is true but for me it is a different protocol which is not a
networking protocol but a protocol for a security device.
> > I took the path of implementing the protocol handler for
> > my protocol using an example from
> > http://www.mozilla.org/projects/netlib/new-handler.html.
>
> That sounds like the right way to go... now why do you need nsIDocument, exactly?
I was basically copying GetScriptContextFromJSContext(cx) code from
nsXmlHttpRequest.cpp which is further called by the GetLoadGroup()
method. I need LoadGroup for the same reasons as XmlHttpRequest i.e to
automatically abort the pending requests if user leaves the page and
pass it to the NS_NewChannel method. Is there any other way to obtain
the LoadGroup ?
Thanks Boris, appreciate your help and looking for further suggestions.
Regards
Kapil
>
> -Boris
Boris Zbarsky
> That is true but for me it is a different protocol which is not a
> networking protocol but a protocol for a security device.
Why does that matter, if it implements nsIProtocolHandler?
> I was basically copying GetScriptContextFromJSContext(cx) code from
> nsXmlHttpRequest.cpp which is further called by the GetLoadGroup()
> method. I need LoadGroup for the same reasons as XmlHttpRequest i.e to
> automatically abort the pending requests if user leaves the page and
> pass it to the NS_NewChannel method. Is there any other way to obtain
> the LoadGroup ?
Not in a frozen way, no....
-Boris
ksachdeva
Boris Zbarsky wrote:
> ksachdeva wrote:
> > That is true but for me it is a different protocol which is not a
> > networking protocol but a protocol for a security device.
>
> Why does that matter, if it implements nsIProtocolHandler?
hmm, excellent point, I now see why you mentioned other protocols. I
quickly looked in the code of nsXmlHttpRequest.cpp and I see lot of
references of nsIHttpChannel. Doesn't this imply dependence on Http
channel and how does this work with ftp and file ?. I have not used
these protocols in XmlHttpRequest but I am taking your word as you are
the guru here :).
On the positive side in the header file for XmlHttpRequest the type
used is IChannel and I can see in various places QI on channel
expecting httpchannel is properly checked in the code.
I am going to give my protocol handler a try from the XmlHttpRequest
but I have doubts after seeing the dependence on HttpChannel.
Thanks Boris, I would post shortly in this thread about the result.
Boris Zbarsky
> hmm, excellent point, I now see why you mentioned other protocols. I
> quickly looked in the code of nsXmlHttpRequest.cpp and I see lot of
> references of nsIHttpChannel. Doesn't this imply dependence on Http
> channel and how does this work with ftp and file ?. I have not used
> these protocols in XmlHttpRequest but I am taking your word as you are
> the guru here :).
XMLHttpRequest can do some things with HTTP that it can't do with others
protocols (for example, POST requests, handling of error status codes to mean
the response should not be parsed, etc). But it can be used to just fetch data
from any protocol that we have a protocol handler for. If you need to do more
than just load a URI (equivalent of an HTTP GET), then XMLHttpRequest might be
difficult to use.
Again, subject to same-origin security checks if the caller is not privileged.
-Boris
ksachdeva
For me it is more than loading the URI. Need to have some functionality
like POST but I think I can put my data as part of URI !!
>
> Again, subject to same-origin security checks if the caller is not privileged.
This would be a problem !! This means that XmlHttpRequest will check
the privileges irrespective of protocol handler ?. In this case I would
not be able to use it as I intend to communicate with a device attached
to the machine.
I am back to my problem again. You mentioned that it would not be
possible to get the LoadGroup in a frozen way. Seems like I am stuck
and may need to compile my extension for different versions of Firefox.
Thanks again.
Regards
Kapil
> -Boris
Boris Zbarsky
>> Again, subject to same-origin security checks if the caller is not privileged.
>
> This would be a problem !! This means that XmlHttpRequest will check
> the privileges irrespective of protocol handler ?
Yes.
> In this case I would not be able to use it as I intend to communicate with a device attached
> to the machine.
From untrusted script?
> I am back to my problem again. You mentioned that it would not be
> possible to get the LoadGroup in a frozen way. Seems like I am stuck
> and may need to compile my extension for different versions of Firefox.
Yeah... Or use as single binary with QI to different IID values for nsIDocument
to figure out which version you're using or something...
-Boris
ksachdeva
> ksachdeva wrote:
> >> Again, subject to same-origin security checks if the caller is not privileged.
> >
> > This would be a problem !! This means that XmlHttpRequest will check
> > the privileges irrespective of protocol handler ?
>
> Yes.
>
> > In this case I would not be able to use it as I intend to communicate with a device attached
> > to the machine.
>
> From untrusted script?
There are 2 reasons why I see it is not a problem - My security device
does not open its doors unless you authenticate and more importantly
all communication is over a secure channel. Second reason is that
Firefox pops up a dialog for user consent to allow access of native
resource from remote script (which is a good thing but dialog box is
ugly and its contents are not fair).
>
> > I am back to my problem again. You mentioned that it would not be
> > possible to get the LoadGroup in a frozen way. Seems like I am stuck
> > and may need to compile my extension for different versions of Firefox.
>
> Yeah... Or use as single binary with QI to different IID values for nsIDocument
> to figure out which version you're using or something...
>
This is a good pointer.
Boris, you have been very helpful, learnt a lot from you.
regards
Kapil
> -Boris
Boris Zbarsky
>> From untrusted script?
>
> There are 2 reasons why I see it is not a problem
I'm not judging what you're doing; just trying to understand what you need to
work. ;)
-Boris