response.redirect

How to send more than one value using response redirect?
For example i can send one like this
response.Redirect "pregled.asp?ime=" & strUserName
but how to send two or more values?
I tried
response.Redirect("pregled.asp?ime=" & strUserName & " & prezime = " &
strUserLastName)
but it didn't work.

Re: response.redirect

gigi wrote:
> How to send more than one value using response redirect?
> For example i can send one like this
> response.Redirect "pregled.asp?ime=" & strUserName
> but how to send two or more values?
> I tried
> response.Redirect("pregled.asp?ime=" & strUserName & " & prezime =
> " & strUserLastName)
> but it didn't work.

Well, I am no ASP expert but I do know that the second and subsequent
parmaters in a call to a URL must be preceded by "&"

So, try
response.Redirect("pregled.asp?ime=" & strUserName & "&prezime=" &
strUserLastName)

Now I look at it, this is the same as yours, except you have some blanks -
before and after the "&" and before and after the "="

That is, you have
& " & prezime = " & strUserLastName

whereas I have
& "&prezime=" & strUserLastName

Whether this makes a difference or not, I really don't know. Mine is not
tested.
--
Cheers,
Trevor L.
[ Microsoft MVP - FrontPage ]
MVPS Website: http://trevorl.mvps.org/
----------------------------------------

Re: response.redirect

Trevor L. wrote on 04 dec 2006 in microsoft.public.inetserver.asp.general:

> So, try
> response.Redirect("pregled.asp?ime=" & strUserName & "&prezime=" &
> strUserLastName)
>

When using the default vbsctiprt the () are not neccesary:

response.Redirect "pregled.asp"

will do.

However, when testing it seems the querystring is not used.

so better use session variables:

========= origin.asp:

<%

..............

session("ime") = strUserName
session("prezime") = strUserLastName
response.redirect "pregled.asp"
%>

============= pregled.asp:

<%
ime = session("ime")
prezime = =session("prezime")
%>



--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

Re: response.redirect

"Evertjan." wrote in message
news:Xns988F5E722C284eejj99@194.109.133.242...
> Trevor L. wrote on 04 dec 2006 in microsoft.public.inetserver.asp.general:
>
> > So, try
> > response.Redirect("pregled.asp?ime=" & strUserName & "&prezime=" &
> > strUserLastName)
> >
>
> When using the default vbsctiprt the () are not neccesary:
>
> response.Redirect "pregled.asp"
>
> will do.
>
> However, when testing it seems the querystring is not used.
>
> so better use session variables:
>
> ========= origin.asp:
>
> <%
>
> .............
>
> session("ime") = strUserName
> session("prezime") = strUserLastName
> response.redirect "pregled.asp"
> %>
>
> ============= pregled.asp:
>
> <%
> ime = session("ime")
> prezime = =session("prezime")
> %>


That depends on whether those values act as part of the resulting resource's
identity. For example pregled.asp could set response headers allowing proxy
and client caching of the generated response. If that is the case you would
want the values included in the querystring.

>
>
>
> --
> Evertjan.
> The Netherlands.
> (Please change the x'es to dots in my emailaddress)

Re: response.redirect

Anthony Jones wrote on 04 dec 2006 in
microsoft.public.inetserver.asp.general:

>> <%
>>
>> .............
>>
>> session("ime") = strUserName
>> session("prezime") = strUserLastName
>> response.redirect "pregled.asp"
>> %>
>>
>> ============= pregled.asp:
>>
>> <%
>> ime = session("ime")
>> prezime = =session("prezime")
>> %>
>
>
> That depends on whether those values act as part of the resulting
> resource's identity. For example pregled.asp could set response
> headers allowing proxy and client caching of the generated response.

What depends on what?

Are the values any different if they act as something?

What does it matter if pregled.asp sets headers,
as it is the receiving page?

Could you please translate that to plain language?

> If that is the case you would want the values included in the
> querystring.

Of course one could want a lot.

However is it possible using response.redirect ?

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

Re: response.redirect

> That is, you have
> & " & prezime = " & strUserLastName
>
> whereas I have
> & "&prezime=" & strUserLastName
>
> Whether this makes a difference or not, I really don't know. Mine is not
> tested.

It works without blanks, thanks.
Thanks also for other answers, but i have to do it with query string.

Re: response.redirect

"Evertjan." wrote in message
news:Xns988F763BD1250eejj99@194.109.133.242...
> Anthony Jones wrote on 04 dec 2006 in
> microsoft.public.inetserver.asp.general:
>
> >> <%
> >>
> >> .............
> >>
> >> session("ime") = strUserName
> >> session("prezime") = strUserLastName
> >> response.redirect "pregled.asp"
> >> %>
> >>
> >> ============= pregled.asp:
> >>
> >> <%
> >> ime = session("ime")
> >> prezime = =session("prezime")
> >> %>
> >
> >
> > That depends on whether those values act as part of the resulting
> > resource's identity. For example pregled.asp could set response
> > headers allowing proxy and client caching of the generated response.
>
> What depends on what?

Whether using session variables in the way you describe is viable depends on
whether those values act as part of the resulting resource's identity. (If
that isn't plain english enough try the HTTP specification)

>
> Are the values any different if they act as something?

Values themselves aren't but the fact that the client and any intervening
proxies never see them is significant.

>
> What does it matter if pregled.asp sets headers,
> as it is the receiving page?
>
> Could you please translate that to plain language?
>

Ok here is a scenario:-

The original page stores values in the Session object then redirects to
'pregled.asp'.
The client receives the redirect status code and requests 'pregled.asp'
Pregled.asp executes and specifies in the response headers that the content
of the response can be cached for an hour.
Client receives OK status code and caches the response (as specified by the
headers).
A few minutes later the client visits the original page again.
The original page stores values in the Session object which differ from the
ones used earlier.
It the redirects to 'pregled.asp'
The client receives the redirect status code and requests 'pregled.asp'
again.
However this time the local cache on the client has a fresh instance of the
response from the 'pregled.asp' URL so it supplies the cached resource to
the browser rather than actually requesting it from the server. The request
for pregled.asp that the original page is expecting never happens.

OTH had the values that vary been placed in the URL as part of the
querystring this problem would not occur.

> > If that is the case you would want the values included in the
> > querystring.
>
> Of course one could want a lot.
>
> However is it possible using response.redirect ?

Yes.

You should've also noted in your solution that care should be taken to
remove those session values else the Session object could be overburdened
with unnecessary values that are no longer needed. This can hurt the
scalability of the application.

>
> --
> Evertjan.
> The Netherlands.
> (Please change the x'es to dots in my emailaddress)

Re: response.redirect

Anthony Jones wrote on 04 dec 2006 in
microsoft.public.inetserver.asp.general:

[..]

> You should've also noted in your solution that care should be taken to
> remove those session values else the Session object could be
> overburdened with unnecessary values that are no longer needed. This
> can hurt the scalability of the application.

I am sorry but I am not convinced:

1 if the session variables are not available due to a reload from the
browsers history() the code can easily default back to another page.

2 if you expect problems when the session variables are still available
when 'pregled.asp' is accessed along another route, they could be reset
after use in 'pregled.asp'

ime = session("ime")
prezime = =session("prezime")
session("ime") = ""
session("prezime") = ""

.... but in general not removing them could be a beneficial solution to my
point number 1.

3 if the page is reloaded from local cache there is no problem since the
serverside execution is not repeated, and serverside processing of the
querystring is not repeated.

4 If you fear that session variables will overburden your server better
not use them at all, but that has not much to do with my simple
alternative to the missing querystring in a response.redirect. An OP
asking this OQ will not encounter that kind of problem, I am quite
certain.

5 Using response.redirect might be not the right solution at all if you
[general you] see so many ghost on that way. Server.transfer might be a
valid alternative in some cases.


--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

Re: response.redirect

"Evertjan." wrote in message
news:Xns988FA8554938Beejj99@194.109.133.242...
> Anthony Jones wrote on 04 dec 2006 in
> microsoft.public.inetserver.asp.general:
>
> [..]
>
> > You should've also noted in your solution that care should be taken to
> > remove those session values else the Session object could be
> > overburdened with unnecessary values that are no longer needed. This
> > can hurt the scalability of the application.
>
> I am sorry but I am not convinced:
>
> 1 if the session variables are not available due to a reload from the
> browsers history() the code can easily default back to another page.

That doesn't make any sense can you elobrate?

>
> 2 if you expect problems when the session variables are still available
> when 'pregled.asp' is accessed along another route, they could be reset
> after use in 'pregled.asp'
>
> ime = session("ime")
> prezime = =session("prezime")
> session("ime") = ""
> session("prezime") = ""

Better yet:-

Session.Contents.Remove "ime"
Session.Contents.Remove "prezime"

This stops a pile of unused key/value pairs building up in the session
object.

>
> ... but in general not removing them could be a beneficial solution to my
> point number 1.
>
> 3 if the page is reloaded from local cache there is no problem since the
> serverside execution is not repeated, and serverside processing of the
> querystring is not repeated.

Again that isn't make any sense.

>
> 4 If you fear that session variables will overburden your server better
> not use them at all, but that has not much to do with my simple
> alternative to the missing querystring in a response.redirect. An OP
> asking this OQ will not encounter that kind of problem, I am quite
> certain.

Your probably right and yet the querystring solution is still the
appropriate solution in the OPs case.

>
> 5 Using response.redirect might be not the right solution at all if you
> [general you] see so many ghost on that way. Server.transfer might be a
> valid alternative in some cases.

Now at least we can agree on that.

>
>
> --
> Evertjan.
> The Netherlands.
> (Please change the x'es to dots in my emailaddress)

Re: response.redirect

Anthony Jones wrote on 04 dec 2006 in
microsoft.public.inetserver.asp.general:

>
> "Evertjan." wrote in message
> news:Xns988FA8554938Beejj99@194.109.133.242...
>> Anthony Jones wrote on 04 dec 2006 in
>> microsoft.public.inetserver.asp.general:
>>
>> [..]
>>
>> > You should've also noted in your solution that care should be taken
>> > to remove those session values else the Session object could be
>> > overburdened with unnecessary values that are no longer needed.
>> > This can hurt the scalability of the application.
>>
>> I am sorry but I am not convinced:
>>
>> 1 if the session variables are not available due to a reload from the
>> browsers history() the code can easily default back to another page.
>
> That doesn't make any sense can you elobrate?

if session("ime") = "" then response.redirect "/"

>>
>> 2 if you expect problems when the session variables are still
>> available when 'pregled.asp' is accessed along another route, they
>> could be reset after use in 'pregled.asp'
>>
>> ime = session("ime")
>> prezime = =session("prezime")
>> session("ime") = ""
>> session("prezime") = ""
>
> Better yet:-
>
> Session.Contents.Remove "ime"
> Session.Contents.Remove "prezime"

certainly!

>
> This stops a pile of unused key/value pairs building up in the session
> object.

Not so important, unless you are planning to have loads of session
variables and thousands of concurrent sessions.

>> ... but in general not removing them could be a beneficial solution
>> to my point number 1.
>>
>> 3 if the page is reloaded from local cache there is no problem since
>> the serverside execution is not repeated, and serverside processing
>> of the querystring is not repeated.
>
> Again that isn't make any sense.

It does:

If the page is client cache reloaded and the original querystring was
only used serverside, the page would be exactly the same with or without
the querystring being there.

>>
>> 4 If you fear that session variables will overburden your server
>> better not use them at all, but that has not much to do with my
>> simple alternative to the missing querystring in a response.redirect.
>> An OP asking this OQ will not encounter that kind of problem, I am
>> quite certain.
>
> Your probably right and yet the querystring solution is still the
> appropriate solution in the OPs case.
>
>>
>> 5 Using response.redirect might be not the right solution at all if
>> you [general you] see so many ghost on that way. Server.transfer
>> might be a valid alternative in some cases.
>
> Now at least we can agree on that.

I would never transport name/forname content in a querystring from one
page to the other, but keep them serverside once they are under my
control. The thought of them being kept in the browser address cache for
anyone to read! And for the first transport to serveside I would use
form/post.

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

Re: response.redirect

"Evertjan." wrote in message
news:Xns98901160A4D8eejj99@194.109.133.242...
> Anthony Jones wrote on 04 dec 2006 in
> microsoft.public.inetserver.asp.general:
>
> >
> > "Evertjan." wrote in message
> > news:Xns988FA8554938Beejj99@194.109.133.242...
> >> Anthony Jones wrote on 04 dec 2006 in
> >> microsoft.public.inetserver.asp.general:
> >>
> >> [..]
> >>
> >> > You should've also noted in your solution that care should be taken
> >> > to remove those session values else the Session object could be
> >> > overburdened with unnecessary values that are no longer needed.
> >> > This can hurt the scalability of the application.
> >>
> >> I am sorry but I am not convinced:
> >>
> >> 1 if the session variables are not available due to a reload from the
> >> browsers history() the code can easily default back to another page.
> >
> > That doesn't make any sense can you elobrate?
>
> if session("ime") = "" then response.redirect "/"

Not very friendly to the user is it. By placing the values in the Session
instead of on the query string you give the user a poor experience if the
press the refresh button. Tell me again what advantage is this providing
host, client or user?

>
> >>
> >> 2 if you expect problems when the session variables are still
> >> available when 'pregled.asp' is accessed along another route, they
> >> could be reset after use in 'pregled.asp'
> >>
> >> ime = session("ime")
> >> prezime = =session("prezime")
> >> session("ime") = ""
> >> session("prezime") = ""
> >
> > Better yet:-
> >
> > Session.Contents.Remove "ime"
> > Session.Contents.Remove "prezime"
>
> certainly!
>
> >
> > This stops a pile of unused key/value pairs building up in the session
> > object.
>
> Not so important, unless you are planning to have loads of session
> variables and thousands of concurrent sessions.

The technique you've described can result in just that, the build up of
loads of unwanted session variables.

>
> >> ... but in general not removing them could be a beneficial solution
> >> to my point number 1.
> >>
> >> 3 if the page is reloaded from local cache there is no problem since
> >> the serverside execution is not repeated, and serverside processing
> >> of the querystring is not repeated.
> >
> > Again that isn't make any sense.
>
> It does:
>
> If the page is client cache reloaded and the original querystring was
> only used serverside, the page would be exactly the same with or without
> the querystring being there.

No it won't. I thought I had made that plain. I'll try again with a
simpler worked example.

Take this page and call it fruit.asp :-

<%

Dim sFruit: sFruit = Session("Fruit")
Session.Contents.Remove("Fruit")
If IsEmpty(sFruit) Then sFruit = "Fruit? What fruit?"
Response.ContentType = "text/html"
Response.CharSet = "Windows-1252"
Response.Expires = 15
Response.CacheControl = "max-age:900"

%>

<%=sFruit%>


and this page we'll call it fruitredir.asp:-

<%
Session("fruit") = Request.QueryString("fruit")
Response.Redirect "fruit.asp"
%>

Visit /fruitredir.asp?fruit=apples. You get apples. Visit
/fruitredir.asp?fruit=oranges you still get apples. If you refresh, the
server has forgotten what fruit you wanted to talk about. Contrast that
with this:-

Fruit.asp:-

<%

Dim sFruit: sFruit = Request.QueryString("Fruit")
If IsEmpty(sFruit) Then sFruit = "Fruit? What fruit?"
Response.ContentType = "text/html"
Response.CharSet = "Windows-1252"
Response.Expires = 15
Response.CacheControl = "max-age:900"

%>

<%=sFruit%>


FruitRedir.asp:-

<%
Dim sFruit: sFruit = Request.QueryString("fruit")
Response.Redirect "fruit.asp?fruit=" & sFruit
%>


Visit /fruitredir.asp?fruit=bananas. You get bananas. Visit
/fruitredir.asp?fruit=grapes you get grapes. Press refresh you still have
grapes. Re-visit /fruitredir.asp?fruit=bananas and the
/fruit.asp?fruit=bananas resource is retrieved from the cache. This is ok
because it shows bananas and is what the original server intended to happen.

>
> >>
> >> 4 If you fear that session variables will overburden your server
> >> better not use them at all, but that has not much to do with my
> >> simple alternative to the missing querystring in a response.redirect.
> >> An OP asking this OQ will not encounter that kind of problem, I am
> >> quite certain.
> >
> > Your probably right and yet the querystring solution is still the
> > appropriate solution in the OPs case.
> >
> >>
> >> 5 Using response.redirect might be not the right solution at all if
> >> you [general you] see so many ghost on that way. Server.transfer
> >> might be a valid alternative in some cases.
> >
> > Now at least we can agree on that.
>
> I would never transport name/forname content in a querystring from one
> page to the other, but keep them serverside once they are under my
> control. The thought of them being kept in the browser address cache for
> anyone to read! And for the first transport to serveside I would use
> form/post.
>
> --
> Evertjan.
> The Netherlands.
> (Please change the x'es to dots in my emailaddress)

Re: response.redirect

Anthony Jones wrote on 06 dec 2006 in
microsoft.public.inetserver.asp.general:

>> > That doesn't make any sense can you elobrate?
>>
>> if session("ime") = "" then response.redirect "/"
>
> Not very friendly to the user is it. By placing the values in the
> Session instead of on the query string you give the user a poor
> experience if the press the refresh button.

You are nitpicking, Anthony,
I was showing you the possibilities you asked for,
not a practical script.

> Tell me again what
> advantage is this providing host, client or user?

Why? If I have told you, read it again, if not,
your question is unfounded.

> [..]

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

Re: response.redirect

"Evertjan." wrote in message
news:Xns9891B4767C0E7eejj99@194.109.133.242...
> Anthony Jones wrote on 06 dec 2006 in
> microsoft.public.inetserver.asp.general:
>
> >> > That doesn't make any sense can you elobrate?
> >>
> >> if session("ime") = "" then response.redirect "/"
> >
> > Not very friendly to the user is it. By placing the values in the
> > Session instead of on the query string you give the user a poor
> > experience if the press the refresh button.
>
> You are nitpicking, Anthony,
> I was showing you the possibilities you asked for,
> not a practical script.
>

A phrase containing the words pot, kettle and black comes to mind.

> > Tell me again what
> > advantage is this providing host, client or user?
>
> Why? If I have told you, read it again, if not,
> your question is unfounded.
>

Quite right you didn't say what advantage it had.

> > [..]
>
> --
> Evertjan.
> The Netherlands.
> (Please change the x'es to dots in my emailaddress)