"Evertjan." <ex**************@interxnl.net> wrote in message
news:Xn*******************@194.109.133.29...
: Roland Hall wrote on 09 feb 2005 in
: microsoft.public.inetserver.asp.general:
:
: > "Evertjan." <ex**************@interxnl.net> wrote in message
: >: so it is a clientside issue. ASP doesn't know or care what browser it
: >: sends his rendered html output to.
: >
: > Which is why it doesn't make any sense. Why does IE fail and Firefox
: > work, everytime?
:
: If that is rue, it is debugable.
It's ridiculous that a client makes a difference to server-script!
: As I said, I suspect it is a security settings issue.
Since when does a security setting make something work sometimes and not
others?
: >:
: >: if session("ticket") = 0 or session("ticket")="" then
: >:
: >: will cover all possibilities.
: >
: > So, session("ticket") = "" is equal to IsEmpty(session("ticket")) ?
:
: I wouldn't know. There is no reason to use the second.
Then why do you think IsEmpty was created if it is never needed?
: >: session("ticket") = 0 can ony be returned if it was initialiszed
: >: somewhere else serverside.
: >
: > It is initialized as 0 in the beginning, then it is set based upon the
: > ticket number given when the first item is added to the cart.
: > The receipt pages, which this issue happens, the very last line of
: > code calls for a sub(routine) which resets the value to 0.
:
: ok, but then it is not a new session.
Semantics
: >: > Response.Clear
: >: > Response.Redirect("/")
: >:
: >: Response.Clear is unnecessary before a redirect.
: >: Any cached html-to-be-sent will be deatroyed anyway.
: >
: > Then there is a lot of misinformation because I have read
: > Response.Clear should be used if Response.Redirect is being called
: > inline.
:
: "inline"? what do you mean?
You don't know what inline code refers to? It's not in a function or a
subroutine. It's inline.
: >: If html is already sent [by a response.flush?]
: >
: > I tried using Response.Flush but with a Response.Redirect it has an
: > issue and after it is too late, at least on this page.
:
: No, I mean that if Response.Flush is used, Response.Redirect is logically
: and factually impossible, because of the below:
:
: >: Response.Clear cannot stop that and
: >: the Response.Redirect is invalid,
: >: as Response.Redirect sends a header instruction
: >: to the browser to redirect
: >: and cannot do that if the header is already sent.
: >:
: >: > else
: >: > cartid = session("ticket")
: >: > end if
: >: > get form values and assign them to variables
: >: > HTML code is written into strings using ASP - Ex. str = "<html>"...
: >: > ASP variables included where required.
: >:
: >: > As I need to write VBScript code
: >:
: >: Serverside? [also serverside Jscript is possible if you prefer]
: >
: > No, I do not prefer JScript server-side.
:
: As you wish, but there is no "need".
Is this really worth noting?
: >: > , I do that, then add another string
: >: > of HTML code, etc.
: >: > There are 7 strings
: >: > After the third, I grab the shopping cart from an XML file and put
: >: > the results into an array.
: >: > I loop through the array adding the purchased items to the receipt,
: >: > add more HTML code and write the string to the screen.
: >:
: >: Not to the server screen, surely?
: >
: > How can a Response.Write write to the server screen?
: >
: > I am referring to:
: > str = "blah blah blah"
: > Response.Write ("<div>" & str & "</div>" & vbCrLf)
: >
: > in lieu of...
: >
: > str = "blah blah blah"
: > %>
: > <div><%=str%></div>
:
: No matter, that results in the same rendered html.
But it effects the performance of the server differently.
: >: You send the string as rendered html to the browser with a
: >: response.write?
: >
: > see above
: >
: >: > After the strings are assigned and written to the screen, I write
: >: > the receipt, passing the cart ID and the strings to a sub.
: >:
: >: Sorry, I cannot follow you here.
: >
: > The receipt is a file:
: >
: > str, str2, str3, str4, str5, str6 are written to the screen.
: > str, str2, str3, str4, str5, str7 are written to the receipt file.
: >
: > Make sense yet?
: >
: > str = "........."
: > Response.Write str
: >
: > more vbs code
: >
: > str2 = "......." & vbs var & "......"
: > Response.Write str2
: >
: > ... str7
: >
: > writeReceipt cartid, str, str2, str3, str4, str5, str7
: >
: > str6 has a button that is required for the shopper to click on but it
: > not needed in the receipt
: >
: >:
: >: > At the end I have to subs,
: >:
: >: Sorry, I cannot follow you here.
: >
: > Should have said 2 sub(routine)s
: >
: >: > delete the cart file and set the session
: >: > number to 0.
: >
: > delXMLFile cartid
: > delSession cartid
: >
: >: What is a session number? Never heard of that.
: >: [If you mean session-id, do not touch that.]
: >
: > cart session variable (cartid)
: >
: >: > I believe since I'm buffering the page, and the receipt is being
: >: > written, the cart file delete and session initialization are
: >: > happening and then my test at the top is being performed so I
: >: > sometimes do not see the receipt.
: >:
: >: Session initialisation is done by the server system, before the
: >: sesrverside execution of the first page of a session begins. The
: >: server first examines the page request from the browser, and if there
: >: is no [valid] session-id cookie value, the ASP server starts a new
: >: session.
: >
: > But that is not what is happening.
: >
: > Here is a picture of the issue, forget everything else:
: >
: > check cart id. If it is = 0 or empty, redirect the user to the home
: > page. ...
: > more code follows
: > ...
: > ' last 2 lines of code
: > delete the cart file
: > reset cartid to 0
: >
: > The last line of code is being processed before the check cart id
: > above it because that is setting it to zero. I know it's happening
: > because when I remove the last 2 lines and put them in another file,
: > use the button click in "str6" to point to that file, which then runs
: > those routines and then redirects to the home page, it works every
: > time with every browser. However, Firefox worked every time the old
: > way. Yes, you, I and everyone else on the planet understand the
: > browser only works with what the server-side gives it but then the
: > browser shouldn't make a difference and it does. The browser cannot
: > change that value, so it has to be server-side and the last line is
: > the only place it is done on that page.
:
: So it could be cookie acceptance?
If it were a cookie acceptance then moving two subroutines to a different
page would have no effect on it. It also would not work sometimes and not
others.
: > I can only conclude that with Response.Buffer = True, that MSFT is
:
: MSFT, what is that?
The company that wrote the OS, the web server and the browser.
: > processing the whole page before it gives it to the browser, but it
: > appears to be processing external routines before inline conditionals.
:
: Do you mean the ASP engine?
Ya', the engine that processes the ASP code.
: What external routines?
If I include an asp page that has a routine, isn't that an external routine?
: "Inline conditionals" to my mind are simply if..then clauses with the
: true statement and the els statement on the same line.
Correct and my "external" routine is being processed prior to my "inline"
conditional at the top of the page. I've posted code. You don't have to
interpret my meanings.
: > I can't even believe I'm saying that but it appears to be what is
: > happening.
:
: ??
:
: >: You cannot do anything [like cart file delete] before session
: >: initialisation.
: >
: > session variable re-initialization
:
: session variable renaming?
No. Session variable re-initialization.
session("ticket") = 0
session("ticket") = getTickets
session("ticket") = 0
: >: > Why Firefox doesn't have a problem with it or why it
: >: > works sometimes, is confusing. I removed the nocache include and
: >: > now it only fails after 3 successful ones for me.
:
: so the page is cached then?
Cached/not cached, not much difference if it eventually fails without
modifying any code. My browser is not set for caching.
: >: > I've decided to take a different approach. After the receipt is
: >: > written, I call another page to cleanup and then redirect to the
: >: > home page. This effectively eliminates the issue and makes it
: >: > stable.
: >:
: >: > IE
: >: > apparently executes code on the page in some unknown order thus
: >: > making the last line of code excute before the some at the top.
: >:
: >: IE, firefox or any other browser do not execute ASP code at all!!!
: >
: > I know which is why none of this makes any sense. When things are not
: > as they should be, then they are as they shouldn't be.
:
: And you need to start debugging
As soon as MSFT sends me the source code, I'll do that.
: >: Do you perhaps mean clientside code?
: >
: > Nope. Don't have any other than onclick events.
:
: Onclick executes only clientside code.
Which is why I said that is all the client-side code I have.
: >: Do you have clientside vbscript?
: >
: > Nope. All client-side code I write is javascript.
: >
: >: [That will only be executed by IE and not by firefox.]
: >
: > I'm aware. Ok, as if this is not long enough, I'm going to show you
: > the code for the mailinorder in a new page.
--
Roland Hall
/* This information is distributed in the hope that it will be useful, but
without any warranty; without even the implied warranty of merchantability
or fitness for a particular purpose. */
Technet Script Center -
http://www.microsoft.com/technet/scriptcenter/
WSH 5.6 Documentation -
http://msdn.microsoft.com/downloads/list/webdev.asp
MSDN Library -
http://msdn.microsoft.com/library/default.asp