IE Problem: XPath document() function and HTTPS
Steve
I'm using browser-based XSL transformations, obtaining XML files that
specify the corresponding XSL stylesheet to use, all via HTTPS from a Java
App Server (Tomcat 5.5.20 to be precise). One of the XSL stylesheets uses
the XPath document() function to return an XML document. The href attribute
associated with the document() function references a servlet on the Java App
Server that dynamically creates the required XML and returns it. This works
fine when the servlet is accessed via HTTP, but fails in IE (6 and 7) when
the servlet is accessed via HTTPS. Firefox has no such problems.
I look at the server logs, and the HTTP(S) request initiated by document()
is being received by the server and XML content returned. However, IE
displays the following web page:
The XML page cannot be displayed
Cannot view XML input using XSL style sheet. Please correct the error and
then click the Refresh button, or try again later.
--------------------------------------------------------------------------------
The download of the specified resource has failed.
Is there some configuration setting in IE that is preventing this from
working? Is there something I need to do to get this going or is this a
known bug?
Many thanks,
-Steve
Joe Fawcett
news:3A15C5CE-0CB3-466C...@microsoft.com...
cross domain request as you're using a different protocol. You can sometimes
fix this by changing cross domain settings in IE, there are a number of
different sections in the zone security panels.
You could also try the approach of accessing the main XSLT via https.
--
Joe Fawcett (MVP - XML)
http://joe.fawcett.name
Steve
"Joe Fawcett" wrote:
But I'm not using different protocols (i.e., HTTP vs. HTTPS)! The entire
web application is accessed via HTTPS, not just the XML returned by this one
particular document() function call. In other words, the XML document that
contains the initial stylesheet reference is accessed via HTTPS. Thus, I
assume that the referenced stylesheet must be fetched via HTTPS as well,
since how else could it be returned to IE (i.e., there is no HTTP path
available to fetch the stylesheet). This stylesheet then makes a document()
function call back to the same server / same web app to return some
dynamically created XML. This must also be happening via HTTPS, since once
again, there is no HTTP path available.
Thus, I don't understand your reference to a cross domain request since only
HTTPS requests are being made and they're all going to the same web
application on the same server. Anyway, I don't think I can ask my user
community to change IE security settings to have the application work
properly. Unless there are other ideas, it looks like I'm going to have to
change to server-side transformations or tell folks that IE is not supported
(ya right :-).
Thanks,
-Steve
Joe Fawcett
the certificate on the server. Can you type the URL into the browser and
retrieve the file?
Is there an warning related to the certificate.
Hope this helps, it's difficult to track these down when I can't test it for
myself with something like Fiddler to watch the traffic.
Steve
"Joe Fawcett" wrote:
> Sorry I misunderstood. The only thing I can think of is something related to
> the certificate on the server. Can you type the URL into the browser and
> retrieve the file?
> Is there an warning related to the certificate.
>
> Hope this helps, it's difficult to track these down when I can't test it for
> myself with something like Fiddler to watch the traffic.
>
> Joe Fawcett (MVP - XML)
> http://joe.fawcett.name
Thanks for the help Joe. It is a self-signed cert, but I have added it to
IE's trusted cert store. I installed Fiddler 2 which understands HTTPS. I
directly access the HTTPS URL that dynamically returns the XML and all is
fine. However, when I access it via the XSL stylesheet that uses the XPath
document function(), I continue to get a failure in IE (The download of the
specified resource has failed.), but the server's result looks fine. From
Fiddler 2:
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Cache-Control: no-store, no-cache, must-revalidate
Pragma: no-cache
Expires: 0
Content-Type: text/xml;charset=UTF-8
Content-Length: 7960
Date: Mon, 08 Jan 2007 19:44:43 GMT
<?xml version="1.0" encoding="UTF-8"?>
<java version="1.4.2_13" class="java.beans.XMLDecoder">
....
</java>
Thus, it looks to me that there is a bug in MSXML and/or IE. The result is
returned to the browser, yet IE (or is it the MSXML engine inside IE?)
decides for some reason unknown to me that the returned data is somehow
"invalid". I think I'm going to have to re-write everything to perform
server-side transforms. Is there someway I can enter a bug report for IE so
that this gets fixed or at least someone reponsible for the product explains
what the heck is going on?
Thanks,
-Steve
Anthony Jones
Can you try it without the no-store cache control value. Sometimes this
header causes WinInet (the component of windows being used to fetch the
document) some trouble.
> Thanks,
> -Steve
>
>
>
Steve
related to stopping browsers from caching my dynamically generated XML and
things worked in both IE 6 and IE 7 with HTTPS. Unfortunately, the XML got
cached (mmm, even with an HTTPS connection?) and this therefore broke my
application. So, as you originally suggested, I got rid of just no-store but
this caused things to revert back to the old problem. So, it would seem that
setting the no-cache directive is also a problem here. I finally ended up
setting just the "Expires" header to zero and this didn't cause problems with
IE, plus it prevented the XML from being cached in both IE and Firefox (I
guess I was just being too fancy with all my "don't cache this" settings :-)
I am happy with the world again. Thanks to you and thanks to Joe as well.
Cheers,
-Steve
Anthony Jones
> Anthony, you're my new hero :-) I eliminated all the HTTP headers I set
> related to stopping browsers from caching my dynamically generated XML and
> things worked in both IE 6 and IE 7 with HTTPS. Unfortunately, the XML
got
> cached (mmm, even with an HTTPS connection?)
> and this therefore broke my
> application.
Yes WinInet does that. There is a switch somewhere that turns that off for
secure content however I suspect using it will put you back to square one.
When you say it got cached do you mean the a subsquent transform failed to
request the content again?
What ProgIDs are you using to instantiate the MSXML components?
An MSXML3 DOM for example will by default include a pragma:no-cache in the
request to load a DOM. This is what XSL uses internally to implement the
xpath document() function.
> So, as you originally suggested, I got rid of just no-store but
> this caused things to revert back to the old problem.
Hmm... WinInet will be using some logic (known only to itself) to determine
whether or not to actually place the content in the cache. Normally with
plenty of space available it would cache even things that are marked as
no-cache. I suspect in the case where it is both no-cache and secure
content it doesn't.
Fundementally WinInet sometimes uses the cached copy of the file as a means
of streaming it to the requesting client. If it can't create the file on
disk it can't supply it. This problem most often occurs with secure or
no-store PDFs.
> So, it would seem that
> setting the no-cache directive is also a problem here. I finally ended up
> setting just the "Expires" header to zero and this didn't cause problems
with
> IE, plus it prevented the XML from being cached in both IE and Firefox (I
> guess I was just being too fancy with all my "don't cache this" settings
:-)
It's odd as I've pointed out msxml by default will force a resync anyway
despite the values in the cache-control or expires headers.
Steve
"Anthony Jones" wrote:
>
> "Steve" <St...@discussions.microsoft.com> wrote in message
> news:9251A5A9-681F-4218...@microsoft.com...
> > Anthony, you're my new hero :-) I eliminated all the HTTP headers I set
> > related to stopping browsers from caching my dynamically generated XML and
> > things worked in both IE 6 and IE 7 with HTTPS. Unfortunately, the XML
> got
> > cached (mmm, even with an HTTPS connection?)
> > and this therefore broke my
> > application.
>
> Yes WinInet does that. There is a switch somewhere that turns that off for
> secure content however I suspect using it will put you back to square one.
> When you say it got cached do you mean the a subsquent transform failed to
> request the content again?
Yes, that is correct. My XSL stylesheet essentially wraps an HTML form.
The XML
returned through the Xpath document() call made by the stylesheet contains
the current values for the contents of this form. These values can obviously
be changed and the form POSTed. When this happens, control passes back to an
XML document (that one that was requested initially) that describes what
fields are to be included in the form. It is this XML doc that references
the stylesheet mentioned above. If I don't specify any HTTP headers related
to not caching the results of the document() call, then the contents of each
form in the field are the same after the POST as they were before (i.e., a
request to fetch the updated dynamic XML doc is not made)
> What ProgIDs are you using to instantiate the MSXML components?
> An MSXML3 DOM for example will by default include a pragma:no-cache in the
> request to load a DOM. This is what XSL uses internally to implement the
> xpath document() function.
Sorry, I don't know what you mean by a ProgID. Is this some Microsoft
thing? I'm just returning an XML document to a web browser that references a
particular XSL stylesheet. Are you saying that for IE, I need to supply some
type of processing instruction? I assume IE 6 an 7 just uses MSXML3 by
default, right? That's what it seems to be doing for me.
>
> > So, as you originally suggested, I got rid of just no-store but
> > this caused things to revert back to the old problem.
>
> Hmm... WinInet will be using some logic (known only to itself) to determine
> whether or not to actually place the content in the cache. Normally with
> plenty of space available it would cache even things that are marked as
> no-cache. I suspect in the case where it is both no-cache and secure
> content it doesn't.
Well, my experience is that if I put the no-caching directives in my HTTPS
response to a document() function it breaks (sounds like a bug to me), and if
I take them out, it works.
>
> Fundementally WinInet sometimes uses the cached copy of the file as a means
> of streaming it to the requesting client. If it can't create the file on
> disk it can't supply it. This problem most often occurs with secure or
> no-store PDFs.
I think something like this is happening. I'm assuming here that WinInet is
simply incapable of storing the result of a secure Xpath document() call in
memory (i.e., it needs to write it to disk). But, the HTTP header says that
this is not allowed. So, the server successfully returns the document to IE
(and that's exactly what the Fiddler2 trace shows), but it can't be received
by IE because it is unable to store it in memory. Purely a guess, but this
is what seems to be happening.
>
> > So, it would seem that
> > setting the no-cache directive is also a problem here. I finally ended up
> > setting just the "Expires" header to zero and this didn't cause problems
> with
> > IE, plus it prevented the XML from being cached in both IE and Firefox (I
> > guess I was just being too fancy with all my "don't cache this" settings
> :-)
>
> It's odd as I've pointed out msxml by default will force a resync anyway
> despite the values in the cache-control or expires headers.
Well, my guess is that somebody (WinInet, IE, MSXML) needs to write the
response to disk but this is not allowed. By setting "expires 0" we still
allow the response to be cached to disk, but it will never be used again
since it immediately expires. However, this is still a huge security hole.
For example, hypothetically speaking, let's say that this is a banking
application and that the original XML doc that is fetched describes customer
independent information that a referenced stylesheet then turns into some
nice looking HTML. To get customer specific information, we make a
document() call to return an XML document that contains details about a
customer account (account #, balance, etc.). All this is happening over
HTTPS so we're sure that nothing is being sniffed in transit. We also don't
want to have anything cached on disk since this is very sensitive
information. Well, it would seem that the only way to use document() with
HTTPS and IE (there were no problems with HTTP in my testing) is to have its
results cached, all be it with instant expiration. If the end-user is at an
Internet Cafe or some other public access terminal, then the next user simply
has to look in the IE cache to find out all sorts of personal banking
information about a previous user.
Someone may want to bring this to Microsoft's attention, or perhaps I'm just
way out to lunch here.
Thanks,
-Steve