June 17th, 2000, 12:00 PM
burro = donkey. burrow = hole in the ground. some people don't know the difference.
June 21st, 2000, 09:49 PM
I'm going to assume you've appended the data to a URL which also brings the user to a new page.
The URL of this new page is accessed by the read-only property document.url Seems to me you can assign this to a string variable and read the data with the appropriate String and/or RegExp objects.
<BLOCKQUOTE><font size="1" face="Verdana,Arial,Helvetica">quote:</font><HR>Originally posted by rorwell:
October 12th, 2002, 06:58 PM
but your method uses GET variables not POST if the data is appended to the url. The problem with this is that a user can just change the values of the data too easily eg. in a shopping cart system.
October 12th, 2002, 08:07 PM
February 20th, 2003, 11:54 AM
Maybe try cookies
Depending on how much data you're trying to pass along, you might be able to store it in a cookie.
This is an idea a coworker of mine came up with for dealing with a multi-page form on a site that doesn't have PHP. I'll be the one to implement it, though.
We want to send along just a single, small <textarea> from one page to the next. Shouldn't be too difficult and a session cookie will work just fine.
Will need to write a function activated onSubmit to find the textarea's value and copy it to the cookie. Then a script in the page that is the form's action will read the cookie and write its value into the textarea.
July 16th, 2003, 01:04 AM
There are alternate methods to retrieve/read/parse POSTed data.
I know that it is only possible using some server side scripting like ASP/JSP/PHP etc. But is it not possible using JS?
It is also possible using Macromedia Flash, but again these two servers (one sending me the POSTed data and other on which I'm reading that data) have to be the same. Again user should have Flash plug-in installed on his PC. Chances of having Flash plug-in are 90% but what about 10%?
So please please tell me if there is any client side method? My hopes are 0.05%
July 16th, 2003, 09:37 AM
It's unclear from your message who's talking to whom. Normally, a client (browser) POSTs a form to a server which replies with a HTML document.
You seem to be thinking that the target of a POST is another browser (client) rather than a server. Indeed, a POST almost always results in receiving a new document, but it would be a misconception. The document the server sends back to the client after POST may or may not have anything to do with the POSTed data. It's entirely dependent on the target of the POST. If you post to a static page (form action="do_nothing.htm"), for example, the POST data (and GET parameters, for that matter) would simply be disregarded. They would not somehow magically be incorporated into the server's response.
JS does not -- at least not in any browser I know of -- retain access to the POST data that may have been sent to obtain the current page. Nor does it have access to the complete header (parameters like keep-alive, status code, etc.).
Remember that client-side JS doesn't begin to execute until the browser is receiving a document. This document is generated by the server. The server generates its response (the document) after receiving the (complete) query, including any POST data. So to the degree that there would be any stdin on the client side (which there isn't so far as JS is concerned... just events caused by user interaction with the document or scripts), it would be receiving the server's output (HTML document), not the previous client request (POST data).
July 16th, 2003, 11:51 AM
corecomm is right, though. A browser has absolutely no access to POST parameters after a request has been sent. They are not sent back by in the response unless the server-side application has been coded to include them in the returned html. In fact, POST data is to an HTTP request what HTML data is to an HTTP response.
Flash will have the same problem since it runs on the client. Only the server sees the POST data.