Mark
|
| Posted: 06/30/2002, 7:59 AM |
|
Hi,
I have to ask !
I'm having an 'interesting' time learning how to pass form control values
between forms on a page in CCS & seem to get different results depending
upon whether I use GET or POST.
Could someone please give me an explanation as to what the differences are &
when I should use which approach?
Many Thanks.
Mark
|
|
|
 |
DonB
|
| Posted: 06/30/2002, 8:36 AM |
|
GET sends information back tacked onto the URL. POST sends the information
as part of the "body" of the response (using mail as an analogy: it's sort
of like GET "emailing' only the subject line, but POST "emailing" a complete
message). GET is generally considered outmoded, although it does it's job
fine. Also, because of how the information is sent, POST can handle much
more data than a GET.
One conderation is that if you want to hide sensitive info, POST is probably
the way to go. Think about the server log that records the URL of each
request. POSTING will avoid putting your sensitive data into the logfile.
Checkout CCGetFromPost and CCGetFromGet in Common.asp of any of your
projects to see the difference in how the two methods are referenced.
What I've never understood is why the "get" and "post" names. These sound
like "receive" and "send", implying they work in opposite directions. Oh,
well...
"Mark" <mark@markate.demon.co.uk> wrote in message
news:afn6dc$p0q$1@news.codecharge.com...
> Hi,
>
> I have to ask !
> I'm having an 'interesting' time learning how to pass form control values
> between forms on a page in CCS & seem to get different results depending
> upon whether I use GET or POST.
>
> Could someone please give me an explanation as to what the differences are
&
> when I should use which approach?
>
> Many Thanks.
> Mark
>
>
|
|
|
|
Brent
|
| Posted: 06/30/2002, 9:06 AM |
|
"DonB" <7432D63DBB01D03A196B1EDD80E8@comcast.net> wrote:
:GET sends information back tacked onto the URL. POST sends the information
:as part of the "body" of the response (using mail as an analogy: it's sort
:of like GET "emailing' only the subject line, but POST "emailing" a complete
:message). GET is generally considered outmoded, although it does it's job
:fine.
One reason to use GET is if you want the user to be able to bookmark
that URL complete with parameters.
: Also, because of how the information is sent, POST can handle much
:more data than a GET.
You're right. GET will handle at least 2k (probably more with the
newer browsers) but it can get incredibly long quite quickly.
:
:One conderation is that if you want to hide sensitive info, POST is probably
:the way to go. Think about the server log that records the URL of each
:request. POSTING will avoid putting your sensitive data into the logfile.
Keep in mind the user can see POSTed data just by viewing the HTML
source. Also both the POSTed information and the URL's and COOKIES can
be changed by a hacker or maclicous user, and re-sent to the web
server just by resubmitting the page. CCS (and CC) have no way of
determining if the GET/POST/COOKIE information has changed. If you
want Get/Post/Cookie security, you need to roll your own. If you don't
think this is serious, change the parameter (or posted data or cookie
data) that had ?rcdid=3 to ?rcdid=10 and resubmit the page. Or change
custid from 100 to 101 to see the next customer's information. Scary,
isn't it?
:
:Checkout CCGetFromPost and CCGetFromGet in Common.asp of any of your
:projects to see the difference in how the two methods are referenced.
:
:What I've never understood is why the "get" and "post" names. These sound
:like "receive" and "send", implying they work in opposite directions. Oh,
:well...
One of life's little mysteries I guess. I thought "POST" would be
similar to posting a letter. It is somewhat concealed in an envelope
away from prying eyes (it is wrapped inside the HTML code). Probablly
"EMBEDDED" would be a better name for it. And Get should have been
called something like "URLPARAM". If someone knows why they were
called GET and POST, please let us know.
Brent
|
|
|
|
Mark
|
| Posted: 06/30/2002, 9:23 AM |
|
Hi
thanks, that's certainly helped !
I've have two control fields that I want to pass to other forms on the page
& noticed that POST only passed the first one...
So now I POST the first one & GET the second - this retains both values for
other forms, but the POST on the first form 'clears' the second value (which
is what I want).
From what you mentioned previously, it sounded like POST didn't use the
RL - I thought this would be good to hide values from users.... however,
using POST still puts the value in the URL - is this right ?
Other forms on the page are using these values as parameters, set as URL -
I've tried parameter set as FORM, but this doesn't work - presumably it's
only valid within the same form it was created ?
If there's a more elegant way of passing values around, I'd like to know !
Can you pass values between pages this way, or should you always use Session
Variables ?
Regards,
Mark
DonB <7432D63DBB01D03A196B1EDD80E8@comcast.net> wrote in message
news:afn8in$srd$1@news.codecharge.com...
> GET sends information back tacked onto the URL. POST sends the
information
> as part of the "body" of the response (using mail as an analogy: it's sort
> of like GET "emailing' only the subject line, but POST "emailing" a
complete
> message). GET is generally considered outmoded, although it does it's
job
> fine. Also, because of how the information is sent, POST can handle much
> more data than a GET.
>
> One conderation is that if you want to hide sensitive info, POST is
probably
> the way to go. Think about the server log that records the URL of each
> request. POSTING will avoid putting your sensitive data into the logfile.
>
> Checkout CCGetFromPost and CCGetFromGet in Common.asp of any of your
> projects to see the difference in how the two methods are referenced.
>
> What I've never understood is why the "get" and "post" names. These sound
> like "receive" and "send", implying they work in opposite directions. Oh,
> well...
>
>
> "Mark" <mark@markate.demon.co.uk> wrote in message
>news:afn6dc$p0q$1@news.codecharge.com...
> > Hi,
> >
> > I have to ask !
> > I'm having an 'interesting' time learning how to pass form control
values
> > between forms on a page in CCS & seem to get different results depending
> > upon whether I use GET or POST.
> >
> > Could someone please give me an explanation as to what the differences
are
> &
> > when I should use which approach?
> >
> > Many Thanks.
> > Mark
> >
> >
>
>
|
|
|
|
Mark
|
| Posted: 06/30/2002, 12:22 PM |
|
Thanks for the extra details Brent.
Is there a limit to the number of times GET will append to the URL?
I'm trying to add a 3rd value & it just won't do it.
The URL after adding the second value is 56 characters long (inc http:// ..)
If I change the method to POST for that form, I can see the correct value on
the URL, but GET won't append it... any ideas ?
Thanks,
Mark
Brent <bdgridly@mailbolt.com> wrote in message
news:s4auhugj6ki66bpp6rshg93vd5t7u0nd4b@4ax.com...
> "DonB" <7432D63DBB01D03A196B1EDD80E8@comcast.net> wrote:
>
> :GET sends information back tacked onto the URL. POST sends the
information
> :as part of the "body" of the response (using mail as an analogy: it's
sort
> :of like GET "emailing' only the subject line, but POST "emailing" a
complete
> :message). GET is generally considered outmoded, although it does it's
job
> :fine.
>
> One reason to use GET is if you want the user to be able to bookmark
> that URL complete with parameters.
>
> : Also, because of how the information is sent, POST can handle much
> :more data than a GET.
>
> You're right. GET will handle at least 2k (probably more with the
> newer browsers) but it can get incredibly long quite quickly.
> :
> :One conderation is that if you want to hide sensitive info, POST is
probably
> :the way to go. Think about the server log that records the URL of each
> :request. POSTING will avoid putting your sensitive data into the
logfile.
>
> Keep in mind the user can see POSTed data just by viewing the HTML
> source. Also both the POSTed information and the URL's and COOKIES can
> be changed by a hacker or maclicous user, and re-sent to the web
> server just by resubmitting the page. CCS (and CC) have no way of
> determining if the GET/POST/COOKIE information has changed. If you
> want Get/Post/Cookie security, you need to roll your own. If you don't
> think this is serious, change the parameter (or posted data or cookie
> data) that had ?rcdid=3 to ?rcdid=10 and resubmit the page. Or change
> custid from 100 to 101 to see the next customer's information. Scary,
> isn't it?
>
> :
> :Checkout CCGetFromPost and CCGetFromGet in Common.asp of any of your
> :projects to see the difference in how the two methods are referenced.
> :
> :What I've never understood is why the "get" and "post" names. These
sound
> :like "receive" and "send", implying they work in opposite directions.
Oh,
> :well...
>
> One of life's little mysteries I guess. I thought "POST" would be
> similar to posting a letter. It is somewhat concealed in an envelope
> away from prying eyes (it is wrapped inside the HTML code). Probablly
> "EMBEDDED" would be a better name for it. And Get should have been
> called something like "URLPARAM". If someone knows why they were
> called GET and POST, please let us know.
>
> Brent
|
|
|
|
Brent
|
| Posted: 07/01/2002, 11:54 AM |
|
"Mark" <mark@markate.demon.co.uk> wrote:
:Thanks for the extra details Brent.
:
:Is there a limit to the number of times GET will append to the URL?
You can have as many parameters in the URL as you like. I don't worry
until it reaches about 2k characters long!
:
:I'm trying to add a 3rd value & it just won't do it.
:The URL after adding the second value is 56 characters long (inc http:// ..)
:
:If I change the method to POST for that form, I can see the correct value on
:the URL, but GET won't append it... any ideas ?
Why is POST putting the parameter in the URL? It should be embedding
it in the HTML code. If you right click in your browser window and
select view source you'll see the HTML code and the POST parameters
should be in there.
Are you using ASP or PHP? How are you adding the parameters to be
posted?
Brent
:
:Thanks,
:Mark
:
:Brent <bdgridly@mailbolt.com> wrote in message
:news:s4auhugj6ki66bpp6rshg93vd5t7u0nd4b@4ax.com...
:> "DonB" <7432D63DBB01D03A196B1EDD80E8@comcast.net> wrote:
:>
:> :GET sends information back tacked onto the URL. POST sends the
:information
:> :as part of the "body" of the response (using mail as an analogy: it's
:sort
:> :of like GET "emailing' only the subject line, but POST "emailing" a
:complete
:> :message). GET is generally considered outmoded, although it does it's
:job
:> :fine.
:>
:> One reason to use GET is if you want the user to be able to bookmark
:> that URL complete with parameters.
:>
:> : Also, because of how the information is sent, POST can handle much
:> :more data than a GET.
:>
:> You're right. GET will handle at least 2k (probably more with the
:> newer browsers) but it can get incredibly long quite quickly.
:> :
:> :One conderation is that if you want to hide sensitive info, POST is
:probably
:> :the way to go. Think about the server log that records the URL of each
:> :request. POSTING will avoid putting your sensitive data into the
:logfile.
:>
:> Keep in mind the user can see POSTed data just by viewing the HTML
:> source. Also both the POSTed information and the URL's and COOKIES can
:> be changed by a hacker or maclicous user, and re-sent to the web
:> server just by resubmitting the page. CCS (and CC) have no way of
:> determining if the GET/POST/COOKIE information has changed. If you
:> want Get/Post/Cookie security, you need to roll your own. If you don't
:> think this is serious, change the parameter (or posted data or cookie
:> data) that had ?rcdid=3 to ?rcdid=10 and resubmit the page. Or change
:> custid from 100 to 101 to see the next customer's information. Scary,
:> isn't it?
:>
:> :
:> :Checkout CCGetFromPost and CCGetFromGet in Common.asp of any of your
:> :projects to see the difference in how the two methods are referenced.
:> :
:> :What I've never understood is why the "get" and "post" names. These
:sound
:> :like "receive" and "send", implying they work in opposite directions.
:Oh,
:> :well...
:>
:> One of life's little mysteries I guess. I thought "POST" would be
:> similar to posting a letter. It is somewhat concealed in an envelope
:> away from prying eyes (it is wrapped inside the HTML code). Probablly
:> "EMBEDDED" would be a better name for it. And Get should have been
:> called something like "URLPARAM". If someone knows why they were
:> called GET and POST, please let us know.
:>
:> Brent
:
|
|
|
|
Mark
|
| Posted: 07/02/2002, 11:43 AM |
|
Hi Brent,
> :I'm trying to add a 3rd value & it just won't do it.
> :The URL after adding the second value is 56 characters long (inc http://
...)
> :
> :If I change the method to POST for that form, I can see the correct value
on
> :the URL, but GET won't append it... any ideas ?
>
> Why is POST putting the parameter in the URL? It should be embedding
> it in the HTML code. If you right click in your browser window and
> select view source you'll see the HTML code and the POST parameters
> should be in there.
I don't know !
I can see the POST parameter in the source, but it's also on the address
line in theURL.
>
> Are you using ASP or PHP? How are you adding the parameters to be
> posted?
I'm using PHP
I have a number of forms on the page, each one contains a Search record.
The Search record contains a listbox & a button.
The POST (or GET) setting is in the Form properties with a return page of
itself
The Search button has an action of Search with no return page defined
Does this help ?
I found that if I put a return page of itself in the Button properties, then
the POST or GET wouldn't pass the parameter ...
If there's a more correct way of doing this, I'm open to suggestions !
Regards,
Mark
|
|
|
|
Geert van der Ploeg
|
| Posted: 07/03/2002, 12:42 AM |
|
> One of life's little mysteries I guess. I thought "POST" would be
> similar to posting a letter. It is somewhat concealed in an envelope
> away from prying eyes (it is wrapped inside the HTML code). Probablly
> "EMBEDDED" would be a better name for it. And Get should have been
> called something like "URLPARAM". If someone knows why they were
> called GET and POST, please let us know.
I was curious too, and decided to check the RFC's.
In RFC 2616, section 9.3 and 9.5, there's being explained what the intended
use of GET and POST methods, along with all other HTTP methods (like PUT,
DELETE, HEAD, TRACE, etc.)
It seems to me that the GET method was the only intended method to really
"get" data, like webpages, etc.
("The GET method means retrieve whatever information (..)")
The POST method, oppositely, was intended to only really "post" things:
" (...)
POST is designed to allow a uniform method to cover the following functions:
- Annotation of existing resources;
- Posting a message to a bulletin board, newsgroup, mailing list,
or similar group of articles;
- Providing a block of data, such as the result of submitting a
form, to a data-handling process;
- Extending a database through an append operation.
(...)"
The RFC doesn't speak about the POST method being used for "retrieving a
webpage and oh, by the way, just post some application variables".
So, the initial intention justifies the choice of names, I think, but
nowadays it has become a little obscure.
And, indeed, as DonB mentioned, it /is/ a matter of data flowing in opposite
directions, I think.
Regards.
--
Geert van der Ploeg
Triple IT
|
|
|
|
Brent
|
| Posted: 07/04/2002, 7:21 AM |
|
"Mark" <mark@markate.demon.co.uk> wrote:
:Hi Brent,
:
:> :I'm trying to add a 3rd value & it just won't do it.
:> :The URL after adding the second value is 56 characters long (inc http://
:..)
:> :
:> :If I change the method to POST for that form, I can see the correct value
:on
:> :the URL, but GET won't append it... any ideas ?
:>
:> Why is POST putting the parameter in the URL? It should be embedding
:> it in the HTML code. If you right click in your browser window and
:> select view source you'll see the HTML code and the POST parameters
:> should be in there.
:
:I don't know !
:I can see the POST parameter in the source, but it's also on the address
:line in theURL.
Yes, this confused me too. I use GET so I checked my search form and
sure enough the same parameters were also POSTed to the HTML code.
This is different than in CC2. So I asked YS this in a support
question. Below are the responses:
------>
Brent: I have a search form and it does submit the search criteria
using url parameters. But why is the form method always set
to post? As in:
<form method="post"
The form has Preserve Parameters set to "GET". In CC2 we could
specify either GET or POST. But it looks like CCS always
uses POST. Is there a reason for this? Or is there a way
to force the form to use the GET method? TIA
YES: By default the Builders create forms that use POST.
You can easily change this by editing the HTML.
Brent: This is a search form.
If it uses POST by default, why are the parameters also passed in the
URL? It seems to me that it uses both GET and POST on the search
arguments because the parameters are also in the HTML. Is this
correct? If so, why? TIA
YES: The parameters are passed via POST method, but at the same time
the Grid is setup to receive URL parameters via GET, thus the page is
being redirected to itself with the appropriate GET paramaters.
I don't remember details now, but this may be a bug that will be fixed
in the next release. Generally, if both the Search and the Grid are
setup to use the same method, then only one method is used. But if
Search is set to use POST and Grid to receive URL Params, then both
methods are used.
I recommend that you resolve this manually for now, while I'll check
if there is a reason for this behavior.
<-----
So for CCS uses both Post and Get on search forms. Like he said, you
can edit the HTML to change the POST to GET.
:
:>
:> Are you using ASP or PHP? How are you adding the parameters to be
:> posted?
:
:I'm using PHP
:I have a number of forms on the page, each one contains a Search record.
:The Search record contains a listbox & a button.
:The POST (or GET) setting is in the Form properties with a return page of
:itself
:The Search button has an action of Search with no return page defined
:
:Does this help ?
I suspect if you have say 3 search forms on the page, then when you
press Search on form 1, it will lose the search parameters (if there
are any) that were created by the other 2 search forms. That's because
it doesn't know about the other 2 search forms. Have you tried setting
Preserve Parameters to "GET" for the search form and for the Grid
form?
Brent
|
|
|
|
|
