What's the point of this "input" return tag? (please)?

[Big Bill]

----------------------------------------------------------------------------------------
<input type="hidden" name="price" value="139.45">
<input type="hidden" name="qty" value="1">
<input type="hidden" name="units" value="2.00">
<input type="hidden" name="return"
value="www.transmittersrus.com/pages/amtransmitters.htm">
---------------------------------------------------------------------------------------

Just to give you some idea of the context I've included a few
surrounding lines....in the context of a form, what's the point of the
"return" tag? Wouldn't it be more usual to expect people to use the
back button on their browsers? I can't see the point in it. It's been
used as part of a template so along with other wedges of code it's
likely unnecessary on most pages.
So I'm thinking of taking it out of them, then validity testing to see
if I've ballsed something up. I don't think I will, but I'd welcome a
second opinion.

BB

 

[Steve Pugh]

----------------------------------------------------------------------------------------
<input type="hidden" name="price" value="139.45">
<input type="hidden" name="qty" value="1">
<input type="hidden" name="units" value="2.00">
<input type="hidden" name="return"
value="www.transmittersrus.com/pages/amtransmitters.htm">
---------------------------------------------------------------------------------------

Just to give you some idea of the context I've included a few
surrounding lines....in the context of a form, what's the point of the
"return" tag?

Without seeing the code for the form handler on the server it's
impossible to say.

A first guess would be that it's to provide a URL to the form handler
so that when it creates the confirmation page it can include a link to
that URL. Hence the same form handler can be used to handle multiple
forms (good) and create unique confirmation pages for each (good)
linking to relevant pages via a 'continue shopping' or whatever link
(good).

Wouldn't it be more usual to expect people to use the
back button on their browsers?

Depends whether they want to go back, or go forwards.

I can't see the point in it.

Have you read the documentation for your form handler? It's almost
certainly described there.

Steve

 

[Guest]

----------------------------------------------------------------------------------------
<input type="hidden" name="price" value="139.45">
<input type="hidden" name="qty" value="1">
<input type="hidden" name="units" value="2.00">
<input type="hidden" name="return"
value="www.transmittersrus.com/pages/amtransmitters.htm">
---------------------------------------------------------------------------------------

Just to give you some idea of the context I've included a few
surrounding lines....in the context of a form, what's the point of the
"return" tag? Wouldn't it be more usual to expect people to use the
back button on their browsers? I can't see the point in it. It's been
used as part of a template so along with other wedges of code it's
likely unnecessary on most pages.
So I'm thinking of taking it out of them, then validity testing to see
if I've ballsed something up. I don't think I will, but I'd welcome a
second opinion.

Often you need a "return" or "location" URL to point to wherever you
left off from, for example, PayPal uses return url's to determine where
to send a visitor after a successful payment. In the case of a shopping
cart (which is what that form looks like) it could be for a "Continue
Shopping" type of link.

Also, doing a "return" or (issuing a Location: header) can solve issues
with people hitting "Reload". Example, if you submit a form to some
script some place, it logs your data, then you hit "Reload" (or in some
cases "Back") your data gets sent to the CGI script again, creating a
duplicat entry. Using Location avoids this because hitting "Reload" will
reload the page you were redirected to.

I'd leave it in unless it disturbs you.

Jamie

 

[Big Bill]

Without seeing the code for the form handler on the server it's
impossible to say.

A first guess would be that it's to provide a URL to the form handler
so that when it creates the confirmation page it can include a link to
that URL. Hence the same form handler can be used to handle multiple
forms (good) and create unique confirmation pages for each (good)
linking to relevant pages via a 'continue shopping' or whatever link
(good).


Depends whether they want to go back, or go forwards.


Have you read the documentation for your form handler? It's almost
certainly described there.

I wouldn't even know what one of those was. So I'll leave the code in.
Good job I asked, eh? Thanks Steve.

BB

 

[Big Bill]

Often you need a "return" or "location" URL to point to wherever you
left off from, for example, PayPal uses return url's to determine where
to send a visitor after a successful payment. In the case of a shopping
cart (which is what that form looks like) it could be for a "Continue
Shopping" type of link.

Also, doing a "return" or (issuing a Location: header) can solve issues
with people hitting "Reload". Example, if you submit a form to some
script some place, it logs your data, then you hit "Reload" (or in some
cases "Back") your data gets sent to the CGI script again, creating a
duplicat entry. Using Location avoids this because hitting "Reload" will
reload the page you were redirected to.

I'd leave it in unless it disturbs you.

Jamie

It does a little but since there's something here I don't quite get
I'd better leave it. It's in as well in an entirely separate part of
the page in a mini-form. I've taken that bit out of some pages, noted
which ones, and I'll keep an eye on them to see if problems develop.
The advantage I've got over the guy that built all this stuff is that
I know I don't know what I'm doing, whereas he thought he did. And he
screwed up. Not that it's not recoverable.
Thanks for your help.

BB

 

[Hywel]

I wouldn't even know what one of those was. So I'll leave the code in.
Good job I asked, eh? Thanks Steve.

The form handler is whatever's referred to in the form element's
"action" attribute.

 

[Augustus]

It does a little but since there's something here I don't quite get
I'd better leave it. It's in as well in an entirely separate part of
the page in a mini-form. I've taken that bit out of some pages, noted
which ones, and I'll keep an eye on them to see if problems develop.
The advantage I've got over the guy that built all this stuff is that
I know I don't know what I'm doing, whereas he thought he did. And he
screwed up. Not that it's not recoverable.
Thanks for your help.

Well you don't want to just "leave it" in there

That field is included in the form to give the form handled somewhere to
RETURN the user to when the form action is complete. It should be the URL
to a page on your website that is set to handle the returning user

It really sounds like you need to take a few minutes to sit down and read
the instructions that go along with the script you are using

 

[Big Bill]

Well you don't want to just "leave it" in there

That field is included in the form to give the form handled somewhere to
RETURN the user to when the form action is complete. It should be the URL
to a page on your website that is set to handle the returning user

It really sounds like you need to take a few minutes to sit down and read
the instructions that go along with the script you are using

I'm not using a script. I've had a site dumped in my lap that did a
few things. It didn't validate at all, though, tags all over the shop.
So I'm trying to make it do what it did, which looks like it liaised
with the shopping cart which I'm keeping well clear of, but make it
validate as well. So far I seem to be succeeding but I'm being very
cautious.

BB

 

[Big Bill]

The form handler is whatever's referred to in the form element's
"action" attribute.

action="the-web-page-I-clicked-the-"buy now" link-to-get-to-here-from"

if that gives you a clue. I tried the "continue shopping" button and
that sent me back there as well which I guess is a function of the
"return" input.

BB

 

[Guest]

I'm not using a script. I've had a site dumped in my lap that did a
few things. It didn't validate at all, though, tags all over the shop.
So I'm trying to make it do what it did, which looks like it liaised
with the shopping cart which I'm keeping well clear of, but make it
validate as well. So far I seem to be succeeding but I'm being very
cautious.

If it's not a live site, then I'd say take it out or point it to some
other place & see what happens. Stepping through the script code looking
for "return" would be kind of cumbersome. (depends on the language)

One thing to be VERY cautious about is any form that looks like a
filename being passed in. Those should be removed and/or inspected in the
code to be sure you know what it's doing for security reasons.

Jamie

 

[Big Bill]

If it's not a live site, then I'd say take it out or point it to some
other place & see what happens. Stepping through the script code looking
for "return" would be kind of cumbersome. (depends on the language)

I wouldn't know where the script code is, even.

One thing to be VERY cautious about is any form that looks like a
filename being passed in.

Erm, passed in or parsed in?

Those should be removed and/or inspected in the
code to be sure you know what it's doing for security reasons.

This isn't a live site and won't be for a while. There's a developer
working on the cart proper (it's that weird one from Barclays about
which there was speculation that the guy who developed it rigged it so
you had to go to him personally, holding folding, to get the thing
working properly) and I imagine he'll eyeball what I've been doing at
some stage. It FEELS ok though. Thanks for your help.

BB