showmodaldialog and ASP

[Newt]

I'm using showmodaldialog, the URL for which is an ASP page. The ASP does some processing, and sometimes during the ASP processing, an error occurs, which I trap. The user can then close the ASP page and use an option to fix the error. When the user then reopens the modal dialog, the same error still occurs, almost as if the page was cached. I've checked the MTS components that the ASP is using, and all objects are dropped during processing, so that none are active at the end of the ASP processing

Each time the ASP opens, I want the ASP to be fully processed, and not a cached copy returned. How I can achieve this, or is there something else I need to look at instead.

 

[Evertjan.]

=?Utf-8?B?TmV3dA==?= wrote on 21 apr 2004 in
microsoft.public.inetserver.asp.general:

I'm using showmodaldialog, the URL for which is an ASP page. The ASP
does some processing, and sometimes during the ASP processing, an
error occurs, which I trap. The user can then close the ASP page and
use an option to fix the error. When the user then reopens the modal
dialog, the same error still occurs, almost as if the page was cached.
I've checked the MTS components that the ASP is using, and all
objects are dropped during processing, so that none are active at the
end of the ASP processing.

Each time the ASP opens, I want the ASP to be fully processed, and not
a cached copy returned. How I can achieve this, or is there something
else I need to look at instead.

It depends on the browser listening to directions:

<% Response.Expires = 0 %>

 

[William Morris]

Newt,

Without seeing the code it's hard to say, but there's probably something
else going on there. What you may want to do is replace showmodaldialog
with window.open whenever it's YOU using the application - that way you have
access to View Source, refreshing the page, etc etc etc. Once you've got
the problem isolated, flip the code back.

Silly question: how do you know that the error is fixed? Is it really?

One way to help debug would be to add another process if the user has gone
back in after fixing the error - something trivial but verifiable - so that
you know that it's the second time around and not the first cached. And,
you're probably already doing this, but make sure that you have some sort of
ASP cache control going on as well, something like:

Response.Buffer = True
Response.ExpiresAbsolute = Now() - 1
Response.Expires = 0
Response.CacheControl = "no-cache"

- Wm

--
William Morris
Semster, Seamlyne reProductions
Visit our website, http://www.seamlyne.com, for the most comfortable
historically inspired clothing you can buy!

I'm using showmodaldialog, the URL for which is an ASP page. The ASP does

some processing, and sometimes during the ASP processing, an error occurs,
which I trap. The user can then close the ASP page and use an option to fix
the error. When the user then reopens the modal dialog, the same error still
occurs, almost as if the page was cached. I've checked the MTS components
that the ASP is using, and all objects are dropped during processing, so
that none are active at the end of the ASP processing.

Each time the ASP opens, I want the ASP to be fully processed, and not a

cached copy returned. How I can achieve this, or is there something else I
need to look at instead.

 

[Newt]

Thank-you for the suggestions. As it happens, I've manged to solve it

Part of the problem was that if the ASP has sucessfully finished, then the last bit of code would be to do a response.redirect, which means that I can't put in any other commands which affects the headers, otherwise the response.redirect doesn't work

When I get an error in the ASP, I used response.write to put out a static HTML page.

What I did was to pull the code for the static HTML page into a separate HTML file, and response.redirect to that file

This seems to cure the problem (though I'm not entirely sure why...)

 

[Ken Schaefer]

Some quick points:

a) Cache-control and Expiry are two different things.
b) Response.Buffer has nothing to do with Cache-Control or Expiry
c) Your code is partially redundant:

Response.ExpiresAbsolute = Now() - 1
Response.Expires = 0

both set the HTTP Expires: header, and one is over-writing the other.

d) Who subtracts a number from a date? Surely you'd subtract a date from
another date?

Some "better" code:

' You can info on these in the HTTP v1.1 RFC/spec
Response.ExpiresAbsolute = #1/1/1980#
Response.AddHeader "cache-control", "no-cache, must-revalidate"
Response.AddHeader "pragma", "no-cache"

Cheers
Ken






message : Newt,
:
: Without seeing the code it's hard to say, but there's probably something
: else going on there. What you may want to do is replace showmodaldialog
: with window.open whenever it's YOU using the application - that way you
have
: access to View Source, refreshing the page, etc etc etc. Once you've got
: the problem isolated, flip the code back.
:
: Silly question: how do you know that the error is fixed? Is it really?
:
: One way to help debug would be to add another process if the user has gone
: back in after fixing the error - something trivial but verifiable - so
that
: you know that it's the second time around and not the first cached. And,
: you're probably already doing this, but make sure that you have some sort
of
: ASP cache control going on as well, something like:
:
: Response.Buffer = True
: Response.ExpiresAbsolute = Now() - 1
: Response.Expires = 0
: Response.CacheControl = "no-cache"
:
: - Wm
:
: --
: William Morris
: Semster, Seamlyne reProductions
: Visit our website, http://www.seamlyne.com, for the most comfortable
: historically inspired clothing you can buy!
:
: : > I'm using showmodaldialog, the URL for which is an ASP page. The ASP
does
: some processing, and sometimes during the ASP processing, an error occurs,
: which I trap. The user can then close the ASP page and use an option to
fix
: the error. When the user then reopens the modal dialog, the same error
still
: occurs, almost as if the page was cached. I've checked the MTS components
: that the ASP is using, and all objects are dropped during processing, so
: that none are active at the end of the ASP processing.
: >
: > Each time the ASP opens, I want the ASP to be fully processed, and not a
: cached copy returned. How I can achieve this, or is there something else
I
: need to look at instead.
:
:

 

[William Morris]

a) Cache-control and Expiry are two different things.

Yes, I know. Distinctions get lost in hurried posts from work when your
partner is over your shoulder going "Hey, let's have an update meeting..."

c) Your code is partially redundant:

Yes, it is. The reason for this is that in my experience any one of the
listed methods alone is unreliable. If that's changed then I'm all for
shorter code!

Response.ExpiresAbsolute = Now() - 1
d) Who subtracts a number from a date? [ I do - wm ] Surely you'd subtract a date from
another date?

Implicitly, that's what the code does. Subtraction like that assumes "date
minus n days." While it may upset sensitive tummies and cause baldness
among East Indian orange-backed wombats, it's perfectly valid.

Some "better" code:

' You can info on these in the HTTP v1.1 RFC/spec
Response.ExpiresAbsolute = #1/1/1980#
Response.AddHeader "cache-control", "no-cache, must-revalidate"
Response.AddHeader "pragma", "no-cache"

Roger that. ASPFAQ has similar code.

Slainte!

- Wm