Comments in-line below:

"Anthony Jones" wrote:

> 
> "Steve" <Steve@d...> wrote in message
> news:9251A5A9-681F-4218-B683-0193CD641BA0@m......
> > 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