Re: ASP sessionstate
From: Evertjan. (exjxw.hannivoort_at_interxnl.net)
Date: 02/09/05
- Next message: btopenworld: "database - strange behaviour of one field"
- Previous message: dw: "Re: Dropdown box from database"
- In reply to: Roland Hall: "Re: ASP sessionstate"
- Next in thread: Roland Hall: "Re: ASP sessionstate"
- Reply: Roland Hall: "Re: ASP sessionstate"
- Messages sorted by: [ date ] [ thread ]
Date: 09 Feb 2005 23:53:34 GMT
Roland Hall wrote on 09 feb 2005 in
microsoft.public.inetserver.asp.general:
> "Evertjan." <exjxw.hannivoort@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.
As I said, I suspect it is a security settings issue.
>:
>: 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.
>: 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.
>: > 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?
>: 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".
>: > , 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.
>: 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?
> I can only conclude that with Response.Buffer = True, that MSFT is
MSFT, what is that?
> 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?
What external routines?
"Inline conditionals" to my mind are simply if..then clauses with the
true statement and the els statement on the same line.
> 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?
>: > 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?
>: > 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
>: Do you perhaps mean clientside code?
>
> Nope. Don't have any other than onclick events.
Onclick executes only clientside code.
>
>: 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.
-- Evertjan. The Netherlands. (Replace all crosses with dots in my emailaddress)
- Next message: btopenworld: "database - strange behaviour of one field"
- Previous message: dw: "Re: Dropdown box from database"
- In reply to: Roland Hall: "Re: ASP sessionstate"
- Next in thread: Roland Hall: "Re: ASP sessionstate"
- Reply: Roland Hall: "Re: ASP sessionstate"
- Messages sorted by: [ date ] [ thread ]