Re: TCPSend GET vs POST

This WebDNA talk-list message is from

2007

It keeps the original formatting. numero = 68329
interpreted = N
texte = > Can anyone explain the difference between [TCPSend] GET and > [TCPSend] Post? Is it the same kind of difference as between GET > and POST in HTML forms?The TCPSend context is nothing more than what tells WebDNA to begin transmitting the data inside while connected to a remote server via the TCPConnect context. The use of the GET or POST statement is not part of the TCPSend context itself, which is why it appears between [tcpsend] and [/tcpsend] and not within the brackets (such as [tcpsend get]). When connecting to a web server, the GET or POST statement tells the server what type of connection to expect. If you connect to a server other than a web server, you would not even use the GET or POST statements. If you've ever viewed the transmission of data between a browser and a server, you will see that the browser will issue the statement first, simply to tell the server what type of connection to expect. When you are using the TCPConnect and TCPSend contexts and connecting to a web server, you are in essence building a custom browser session to connect to the server. The goal of your efforts is to look like a browser to the server. In that regard, when you use the GET or POST statements, you are emulating a browser's get and post as used in a form, so it would function the same - there would be no difference.> If you're authorizing a credit card, should you use POST because > it's more secure? I've been testing with Authorize.net, and both > seem to function.POST itself is no more secure than GET. It can appear as more secure because the data is not transmitted in the URL, but a steam watcher can intercept the data as simply as in a GET statement. What makes the connection secure is the use of SSL, which is a parameter that can be selected within the TCPConnect context. In that case, it makes no difference whether you use GET or POST, as both would be encrypted. And, since a connection from your WebDNA server to another server is not visible in the browser window that initiated the script, there would be no browser address field for the data to appear in (as would be the case for a browser to server connection using GET).Typically, however, you should use POST, since it will allow for more that 256 characters to be transmitted. GET is historically limited to 256 characters, but I am sure that WebDNA would have no problem sending whatever you put in the field. The receiving server, though, might be a different story.Dennis-------------------------------------------------------------This message is sent to you because you are subscribed to the mailing list .To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to Web Archive of this list is at: http://webdna.smithmicro.com/ Associated Messages, from the most recent to the oldest:

Re: TCPSend GET vs POST ( Jim Ziegler 2007)
Re: TCPSend GET vs POST ( "Dennis J. Bonsall, Jr." 2007)
TCPSend GET vs POST ( Jim Ziegler 2007)

> Can anyone explain the difference between [tcpsend] GET and > [tcpsend] Post? Is it the same kind of difference as between GET > and POST in HTML forms?The TCPSend context is nothing more than what tells WebDNA to begin transmitting the data inside while connected to a remote server via the TCPConnect context. The use of the GET or POST statement is not part of the TCPSend context itself, which is why it appears between [tcpsend] and [/tcpsend] and not within the brackets (such as [tcpsend get]). When connecting to a web server, the GET or POST statement tells the server what type of connection to expect. If you connect to a server other than a web server, you would not even use the GET or POST statements. If you've ever viewed the transmission of data between a browser and a server, you will see that the browser will issue the statement first, simply to tell the server what type of connection to expect. When you are using the TCPConnect and TCPSend contexts and connecting to a web server, you are in essence building a custom browser session to connect to the server. The goal of your efforts is to look like a browser to the server. In that regard, when you use the GET or POST statements, you are emulating a browser's get and post as used in a form, so it would function the same - there would be no difference.> If you're authorizing a credit card, should you use POST because > it's more secure? I've been testing with Authorize.net, and both > seem to function.POST itself is no more secure than GET. It can appear as more secure because the data is not transmitted in the URL, but a steam watcher can intercept the data as simply as in a GET statement. What makes the connection secure is the use of SSL, which is a parameter that can be selected within the TCPConnect context. In that case, it makes no difference whether you use GET or POST, as both would be encrypted. And, since a connection from your WebDNA server to another server is not visible in the browser window that initiated the script, there would be no browser address field for the data to appear in (as would be the case for a browser to server connection using GET).Typically, however, you should use POST, since it will allow for more that 256 characters to be transmitted. GET is historically limited to 256 characters, but I am sure that WebDNA would have no problem sending whatever you put in the field. The receiving server, though, might be a different story.Dennis-------------------------------------------------------------This message is sent to you because you are subscribed to the mailing list .To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to Web Archive of this list is at: http://webdna.smithmicro.com/ "Dennis J. Bonsall, Jr."

DOWNLOAD WEBDNA NOW!

Re: TCPSend GET vs POST

2007

Top Articles:

Related Readings: